DIR Return Create A Forum - Home
---------------------------------------------------------
Osmania Ortho
HTML https://osmaniaortho.createaforum.com
---------------------------------------------------------
*****************************************************
DIR Return to: General Discussion
*****************************************************
#Post#: 71--------------------------------------------------
Paper presentation--Tips and tricks
By: osmaniaortho Date: March 14, 2012, 8:00 am
---------------------------------------------------------
Some tips for preparing your paper presentation
First, organize your talk:
Read the entire paper at least 3 times.
You need to be able to explain the details in the paper (even
the ugly tricky notation)
You need to be able to provide a critical analysis of the paper
Check out references in the related work section of the paper.
(this will help you put the paper in context of a larger body of
work and will help you critique the paper's
results/contributions)
Look at Paper Reading Advice for more details.
Find the important ideas A paper has many details but only one
or two main ideas; structure your talk around these main ideas.
Create a Talk Outline
Your talk should be organized in a top-down manner.
You should have the following main sections in your talk:
Introduction, The Big Picture: what, why, how, and why we should
care (motivation). Be sure to include:
a statement of the problem being solved (what)
motivation and putting the work in context (why and why should
we care)
a high-level view of the author's solution (how)
Details of solution
Results demonstrating/proving their solution
Critic of Work (possibly compare to related work)
Conclusions & Future Directions for this work
The talk should be organized as the important ideas first, the
details second, conclusions last. Each section of your talk
should be organized in a similar manor: high-level important
points first, details second, summarize high-level points last.
If the paper is well written, you can use the paper's
organization as a guide.
Next, Design your slides
Slide Organization Your slides should be organized like an
outline--a few main points, with sub points under each one.
Your slides are a guide for your talk not a word-for-word copy
of your talk. List specific points that you want to talk about
as sub-topics of each main topic. If there are particular
details that you want to discuss, outline them on the slide and
keep written notes for you to refer to in your talk rather than
writing all the details on the slide.
Summarize Main Points You should have a summary slide of the
main ideas at the end.
If applicable, Include a list of open questions from the paper
It is okay to waste space Add just enough prose prose to present
the main points and highlight the main parts of each point. Use
phrases rather than complete sentences and use large fonts. You
can use acronyms and abbreviations sparingly, however you should
say the complete name when you talk about about them. For
example, if you abbreviate processes to procs on a slide, say
"processes" when you talk about the point not "procs".
Similarly, if your create an acronym for your super fast
multi-cast implementation SFMC and refer to the old slow
multi-cast implementation as OSMC, then say "our super fast
multi-cast" and "the old slow multi-cast" rather than "SFMC" and
"OSMC". The exception is for well-known acronyms such as PVM,
MPI, API, JVM, etc.
A picture is worth a thousand words Use figures and graphs to
explain implementation and results. It is very hard to describe
a system implementation without having a picture of the
components of the system. I once attended a talk about Intel's
I64 architecture where the speaker tried to discuss the details
of the layout of the chip and the interactions between the
components without having any figures. It made for a very bad
talk and a very hostile audience.
Number of Slides As a general rule, it should take 2-3 minutes
to talk through the material on one slide, so for a 45 minute
talk you should have about 20 slides.
If there is too much material in a paper to present completely
in 45 minutes, then pick one part (the most
interesting/important part) that you will discuss in detail, and
present the other parts at a higher level. You can create
back-up slides for specific details that you don't plan to talk
about, but may get questions about.
Next, preparing your presentation
Provide a talk road-map Tell audience where you are going with
your talk.
Give audience a road-map of your talk at the beginning by using
outline slides
Immediately after the title slide, put up an outline slide and
tell the audience the main organization of your talk. Another
alternative is to first have a few slides motivating the paper's
general topic, then put up an outline slide giving the audience
a road-map of your talk.
It should be clear when you start a new high-level part of your
talk
Use good transitions from one slide to the next, and from one
main topic to the next..."We just talked about the
implementation of foo now we will look at how well foo performs
for synthetic and real workloads.
You may want to use the outline slide at other points in your
talk to provide a visual transition between parts.
Repeat Your Point There is a rule that says you have to tell
your audience something three times before the really hear it:
Tell them what you are going to say.
Say it.
Summarize what you said.
This is particularly important for figures and graphs. For
example:
This graph show how the A algorithm performs better than the B
and C algorithms as the number of nodes increase
The X axis is number of nodes, the Y axis is execution time in
seconds The red curve shows the execution time of A as the
number of nodes increases The blue curve shows ...
Thus you can see that as the number of nodes increases above N,
the A algorithm performs better. This is because of increased
message traffic in algorithms B and C as shown on the next
slide...
Explain concepts in your own words It is certainly okay to lift
key phrases from the paper to use in your talk. However, you
should also try to summarize the main ideas of the paper in your
own words.
Talk to the Audience Don't read your slide off the screen, nor
directly off the projector. It is okay to stop for a second and
refer to your notes if you need to.
Practice Give a practice run-through of your talk. Stand in a
room for 1 hour and talk through all your slides (out loud).
This should be a timed dress rehearsal (don't stop and fix
slides as you go). Members of your reading group should provide
a practice audience for you.
Nervousness: How to fight back
A well organized, practiced talk will almost always go well. If
you draw a blank, then looking at your slides will help you get
back on track.
Taking a deep breath will clam you down. One trick is to try to
remember to take a deep breath between each slide.
Slow down. Take a few seconds to think about a question that is
being asked before you answer it. It is okay to pause for a few
seconds between points and between slides; a second or two of
silence between points is noticeable only to you, but if you are
talking a mile a minute everyone will notice.
Bring notes. if you are afraid that you will forget a point or
will forget your elegant transition between slides 11 and 12,
write these down on a piece of paper and bring it with you.
However, you don't want to have a verbatim copy of your talk,
instead write down key phrases that you want to remember to say.
Give at least one practice talk to an audience.
Be prepared to answer questions. You don't have to know the
answer to every question, however you should be prepared to
answer questions and able to answer most questions about the
paper. Before you give the talk, think about what questions you
are likely to get, and how you would answer them. You may want
to have back-up slides ready for answering certain questions.
It is okay to say "I don't know" or better yet "gee, I hadn't
thought about that, but one possible approach would be to..." or
to refer to your notes to answer questions.
#Post#: 72--------------------------------------------------
Re: Paper presentation--Tips and tricks
By: osmaniaortho Date: March 14, 2012, 8:02 am
---------------------------------------------------------
Tips for Writing Technical Papers
HTML http://infolab.stanford.edu/~widom/paper-writing.html
Paper Title
The Abstract
The Introduction
Related Work
The Body
Performance Experiments
The Conclusions
Future Work
The Acknowledgements
Citations
Appendices
Grammar and Small-Scale Presentation Issues
Mechanics
Versions and Distribution
Running Example
As a running (fictitious!) example, suppose you've designed and
run experiments with a new algorithm for external multipass
merge-sort. Your algorithm reduces the complexity from O(n log
n) to O(n), under the premise that it's acceptable to have some
bounded "unsortedness" in the result. You plan to write up the
results for submission to a major conference.
Note: This example was used throughout the live presentation but
I haven't followed through much in these notes. Thus, the notes
include several exercises for the reader.
Paper Title
Titles can be long and descriptive:
Linear-Time External Multipass Sorting with Approximation
Guarantees
or short and sweet:
Approximate External Sort
Here's a middle-of-the-road length, plus a cute name that sticks
in people's minds:
Floosh: A Linear-Time Algorithm for Approximate External Sort
The Abstract
State the problem, your approach and solution, and the main
contributions of the paper. Include little if any background and
motivation. Be factual but comprehensive. The material in the
abstract should not be repeated later word for word in the
paper.
(Exercise: Write an abstract for the multiway sort example.)
The Introduction
The Introduction is crucially important. By the time a referee
has finished the Introduction, he's probably made an initial
decision about whether to accept or reject the paper -- he'll
read the rest of the paper looking for evidence to support his
decision. A casual reader will continue on if the Introduction
captivated him, and will set the paper aside otherwise. Again,
the Introduction is crucially important.
Here is the Stanford InfoLab's patented five-point structure for
Introductions. Unless there's a good argument against it, the
Introduction should consist of five paragraphs answering the
following five questions:
What is the problem?
Why is it interesting and important?
Why is it hard? (E.g., why do naive approaches fail?)
Why hasn't it been solved before? (Or, what's wrong with
previous proposed solutions? How does mine differ?)
What are the key components of my approach and results? Also
include any specific limitations.
(Exercise: Answer these questions for the multiway sort
example.)
Then have a final paragraph or subsection: "Summary of
Contributions". It should list the major contributions in bullet
form, mentioning in which sections they can be found. This
material doubles as an outline of the rest of the paper, saving
space and eliminating redundancy.
(Exercise: Write the bullet list for the multiway sort example.)
Related Work
The perennial question: Should related work be covered near the
beginning of the paper or near the end?
Beginning, if it can be short yet detailed enough, or if it's
critical to take a strong defensive stance about previous work
right away. In this case Related Work can be either a subsection
at the end of the Introduction, or its own Section 2.
End, if it can be summarized quickly early on (in the
Introduction or Preliminaries), or if sufficient comparisons
require the technical content of the paper. In this case Related
Work should appear just before the Conclusions, possibly in a
more general section "Discussion and Related Work".
The Body
Guideline #1: A clear new important technical contribution
should have been articulated by the time the reader finishes
page 3 (i.e., a quarter of the way through the paper).
Guideline #2: Every section of the paper should tell a story.
(Don't, however, fall into the common trap of telling the entire
story of how you arrived at your results. Just tell the story of
the results themselves.) The story should be linear, keeping the
reader engaged at every step and looking forward to the next
step. There should be no significant interruptions -- those can
go in the Appendix; see below.
Aside from these guidelines, which apply to every paper, the
structure of the body varies a lot depending on content.
Important components are:
Running Example: When possible, use a running example throughout
the paper. It can be introduced either as a subsection at the
end of the Introduction, or its own Section 2 or 3 (depending on
Related Work).
Preliminaries: This section, which follows the Introduction and
possibly Related Work and/or Running Example, sets up notation
and terminology that is not part of the technical contribution.
One important function of this section is to delineate material
that's not original but is needed for the paper. Be concise --
remember the critical rule of thumb.
Content: The meat of the paper includes algorithms, system
descriptions, new language constructs, analyses, etc. Whenever
possible use a "top-down" description: readers should be able to
see where the material is going, and they should be able to skip
ahead and still get the idea.
Performance Experiments
We could have an entire treatise on this topic alone and I am
surely not the expert. Here are some random thoughts:
Many conferences expect experiments.
It's easy to do "hokey" or meaningless experiments, and many
papers do.
It's easy to craft experiments to show your work in its best
light, and most papers do.
What should performance experiments measure? Possiblities:
Pure running time
Sensitivity to important parameters
Scalability in various aspects: data size, problem complexity,
...
Others?
What should performance experiments show? Possibilities:
Absolute performance (i.e., it's acceptable/usable)
Relative performance to naive approaches
Relative performance to previous approaches
Relative performance among different proposed approaches
Others?
The Conclusions
In general a short summarizing paragraph will do, and under no
circumstances should the paragraph simply repeat material from
the Abstract or Introduction. In some cases it's possible to now
make the original claims more concrete, e.g., by referring to
quantitative performance results.
Future Work
This material is important -- part of the value of a paper is
showing how the work sets new research directions. I like bullet
lists here. (Actually I like them in general.) A couple of
things to keep in mind:
If you're actively engaged in follow-up work, say so. E.g.: "We
are currently extending the algorithm to... blah blah, and
preliminary results are encouraging." This statement serves to
mark your territory.
Conversely, be aware that some researchers look to Future Work
sections for research topics. My opinion is that there's nothing
wrong with that -- consider it a complement.
The Acknowledgements
Don't forget them or you'll have people with hurt feelings.
Acknowledge anyone who contributed in any way: through
discussions, feedback on drafts, implementation, etc. If in
doubt about whether to include someone, include them.
Citations
Spend the effort to make all citations complete and consistent.
Do not just copy random inconsistent BibTex (or other) entries
from the web and call it a day. Check over your final
bibliography carefully and make sure every entry looks right.
Appendices
Appendices should contain detailed proofs and algorithms only.
Appendices can be crucial for overlength papers, but are still
useful otherwise. Think of appendices as random-access
substantiation of underlying gory details. As a rule of thumb:
Appendices should not contain any material necessary for
understanding the contributions of the paper.
Appendices should contain all material that most readers would
not be interested in.
Grammar and Small-Scale Presentation Issues
In general everyone writing papers is strongly encouraged to
read the short and very useful The Elements of Style by Strunk
and White. Here's a random list of pet peeves.
Just like a program, all "variables" (terminology and notation)
in the paper should be defined before being used, and should be
defined only once. (Exception: Sometimes after a long hiatus
it's useful to remind the reader of a definition.) Global
definitions should be grouped into the Preliminaries section;
other definitions should be given just before their first use.
Do not use "etc." unless the remaining items are completely
obvious.
Acceptable: We shall number the phases 1, 3, 5, 7, etc.
Unacceptable: We measure performance factors such as volatility,
scalability, etc.
Never say "for various reasons". (Example: We decided not to
consider the alternative, for various reasons.) Tell the reader
the reasons!
Avoid nonreferential use of "this", "that", "these", "it", and
so on (Ullman pet peeve). Requiring explicit identification of
what "this" refers to enforces clarity of writing. Here is a
typical example of nonreferential "this": Our experiments test
several different environments and the algorithm does well in
some but not all of them. This is important because ...
(Exercise: The above rule is violated at least once in this
document. Find the violations.)
Italics are for definitions or quotes, not for emphasis (Gries
pet peeve). Your writing should be constructed such that context
alone provides sufficient emphasis.
(Exercise: The above rule is violated at least once in this
document. Find the violations.)
People frequently use "which" versus "that" incorrectly. "That"
is defining; "which" is nondefining. Examples of correct use:
The algorithms that are easy to implement all run in linear
time.
The algorithms, which are easy to implement, all run in linear
time.
Mechanics
Always run a spelling checker on your final paper, no excuses.
For drafts and technical reports use 11 point font, generous
spacing, 1" margins, and single-column format. There's no need
to torture your casual readers with the tiny fonts and tight
spacing used in conference proceedings these days.
In drafts and final camera-ready, fonts in figures should be no
smaller than the font size in the body of the paper.
Tables, figures, graphs, and algorithms should always be placed
on the top of a page or column, not in the body of the text
unless it is very small and fits into the flow of the paper.
Every table, figure, graph, or algorithm should appear on the
same page as its first reference, or on the following page
(LaTex willing...).
Before final submission or publication of your paper, print it
once and take a look -- you might be quite surprised how
different it looks on paper from how it looked on your screen
(if you even bothered to look at it after you ran Latex the last
time...).
Versions and Distribution
Many papers have a submitted (and later published) conference
version, along with a "full paper" technical report on the web.
It's important to manage versions carefully, both in content and
proliferation. My recommendation is, whenever possible, for the
full paper to consist of simply the conference version plus
appendices. The full paper should be the only public one aside
from conference proceedings, it should be coordinated with
latest (final) conference version, and modifications to the full
paper should always overwrite all publicly accessible previous
versions of it.
I believe in putting papers on the web the minute they're
finished. They should be dated and can be referenced as
technical reports -- it's not necessary to have an actual
technical report number. Never, ever put up a paper with a
conference copyright notice when it's only been submitted, and
never, ever reference a paper as "submitted to conference X."
You're only asking for embarrassment when the paper is finally
published in conference Y a year or two later.
*****************************************************