Add notes on paper presentations.
This commit is contained in:
parent
f4c723c78b
commit
422261a922
|
@ -0,0 +1,39 @@
|
||||||
|
During this class, you will be responsible for presenting one paper in class and
|
||||||
|
leading the discussion. [Here](../resources/readings.md) is a list of suggested
|
||||||
|
papers; you are free to choose a paper that is not on the list, but please clear
|
||||||
|
it with me first. The day before each presentation, I will send out a few short
|
||||||
|
questions to check your understanding. Please reply with short responses---a few
|
||||||
|
sentences should be more than enough.
|
||||||
|
|
||||||
|
Research papers are written for a very specific technical audience. Papers
|
||||||
|
appearing in conferences---most papers in computer science---are also subject to
|
||||||
|
tight page limits and are typically extremely condensed; many things are left
|
||||||
|
unsaid. (Here is a useful
|
||||||
|
[guide](https://web.stanford.edu/class/ee384m/Handouts/HowtoReadPaper.pdf) to
|
||||||
|
reading papers.) When presenting a paper in class, you should not try to
|
||||||
|
compress the material from the paper. Instead, you should try to expand and
|
||||||
|
unpack the paper, so that it is easier to understand.
|
||||||
|
|
||||||
|
Here are a few specific things to keep in mind when presenting a paper.
|
||||||
|
|
||||||
|
- **Make sure the high-level picture is clear.** Make sure to explain the
|
||||||
|
problem the paper is trying to solve, the setting, and as much of the
|
||||||
|
motivation behind the paper as possible.
|
||||||
|
- **Don't spend the whole time presenting technical details.** It is probably
|
||||||
|
not interesting for the class to spend the whole presentation talking about
|
||||||
|
the technical details in a single proof.
|
||||||
|
- **You don't have to present the whole paper.** It is simply not possible to
|
||||||
|
present every detail in the span of one lecture. For some papers, it may not
|
||||||
|
even be possible to present each main contribution. Focus on the one or two
|
||||||
|
most important contributions (as decided by yourself). If the paper first
|
||||||
|
discusses a "core" or "basic" version, and then later adds on a bunch of
|
||||||
|
advanced extensions, *focus on the core version*.
|
||||||
|
- **Give as many examples as you can.** Most research papers are extremely
|
||||||
|
condensed, and do not have nearly enough examples. Present as many examples as
|
||||||
|
you can. Your examples don't need to be drawn from the paper---small examples
|
||||||
|
are the most useful, as simple as possible.
|
||||||
|
- **Keep the class background in mind.** Our class has students from a variety
|
||||||
|
of backgrounds; try to keep this in mind. It's better to briefly explain a
|
||||||
|
technical term if you are not sure everyone knows what it means. You should
|
||||||
|
assume that everyone in the class has basic familiarity with the paper (say,
|
||||||
|
assume everyone spent about 30-45 minutes reading the paper before class).
|
|
@ -27,6 +27,7 @@ pages:
|
||||||
- Papers: 'resources/readings.md'
|
- Papers: 'resources/readings.md'
|
||||||
- Software: 'resources/software.md'
|
- Software: 'resources/software.md'
|
||||||
- Related Courses: 'resources/related.md'
|
- Related Courses: 'resources/related.md'
|
||||||
- Project:
|
- Assignments:
|
||||||
- Details: 'projects/details.md'
|
- Presentations: 'assignments/presentations.md'
|
||||||
- Gallery: 'projects/final.md'
|
- Project: 'assignments/project.md'
|
||||||
|
- Gallery: 'assignments/gallery.md'
|
||||||
|
|
Reference in New Issue