# Giving short ML theory research talks

These comments apply to many presentations we’ve seen and address some common mistakes

Note: don’t copy lecture style and slides - short conference talks are fundamentally different than lectures!

## General scope of talk

• Type of talk (ML conference) and beware of community culture

• Treat it like a talk where you present your own work. Note that this differs from EE or TCS or Stats type talks … The latter tend to like to put more math and see more formulas even though that might not actually help understanding it better … Different cultures.

• Mode: give the talk like at a conference. That means: you can’t share slides beforehand or hope people write your notation along - you have to rely on their (limited) memory of previous slides hence limit the amount of uncommon symbols you introduce!

• Hence: do not use the slides in the lecture handouts as an example. They are made with a different purpose in mind (i.e. that you can flip back in the shared presentation/blackboard notes)

• Pick the most substantial results to present

• Don’t just list a bunch of results just because they’re there and you’ve worked hard to prove them

• Only pick the most important results and go into detail in terms of explaining the intuition. In most cases, the main goal is to help the audience understand something interesting, instead of trying to impress them with the breadth of your work. Thinking of audience attention as a scarce resource, you must focus on the main message, as opposed to technical contributions.

• Focus on one main insight from the proof that helps to explain and understand a new phenomenon. The aim is that the audience thinks this is such an interesting new intuitively graspable insight they might want to read through details themselves afterwards. And use the intuition in future papers (and hence cite you ;))

• For the specific case of the class presentation: Please break free from authors notations, their way to present the results etc. Imagine a friend came to you with the results and you are now supposed to sell the story in the best way possible, thinking about writing/telling the story from scratch and examining their choice to present things critically.

## Structure

• Main message teaser

• The problem must be clearly stated in the first few slides (1-2). You must clarify (1) what is the problem? and, (2) why is it important? The audience is not familiar with the paper and topic as you are, so you must avoid technical terms as much as possible.

• After motivating the problem, illustrate main results with figures / drawings (e.g. plots, if paper doesn’t have, produce some) and easy language before introducing any mathematical notation (i.e. to present setting formally) and stating formal theorems

• What’s the most surprising / intriguing result in words and why?

• How is it related to practice?

• Put your paper in the context of existing literature that tackles the same problem perhaps in different ways / with different assumptions

• If you present a computer vision paper do not discuss the imagenet paper. The literature that is relevant to motivate the problem does not need to be mentioned in detail unless noone has tackled the problem before

• Instead, discuss other papers that have tackled the problem! How is this paper different? People need to know in the beginning what your paper’s novel contribution is. But also during the presentation

• Literature review: if you plan to cover more than four papers in the review, you may add each paper to a topic cluster and explain the topic instead. This way it’s more time efficient, and it’s also easier for the audience to get familiar with the concepts.

• After the motivation and teaser: Give them a heads up

• After the audience understood what problem you aim to solve, give them an outline on what to expect in your talk (see lectures). Some go through the outline first - however, if the audience doesn’t know any of the terms in the outline they won’t be able to remember the outline well

• Sometimes in the talk it’s nice to remind them where in the outline you currently are

• Only introduce notation right before you use it (e.g. in theorem), limit number of used math symbols and instead use figures wherever reasonable

• Think about the attention of (any) audience as a (quite) limited budget

• Think carefully which symbols and notations are the most necessary to maximize learning experience, i.e. minimize the number of symbols you use!

• Instead use visuals like plots / diagrams whenever possible. Much easier to remember and to connect different points. But go through them slowly

• However whatever symbols you have to use, make sure the audience knows at every slide what every symbol means and do not use the same symbol for different quantities! (nice side-effect: automatically limits the number of symbols you will use)

• in theorems, do not aim for perfect rigor but for the ability to be intuitively understood (hide constants and things that the audience cannot make sense of in the one minute you’re on that slide) optimize tradeoff between amount of rigorous info vs. intuition.

• Connect to people’s existing knowledge

• Refer to previous knowledge (in our case: lectures) when you use a concept we covered in class. Don’t pretend it’s something we’ve never heard of.

• People learn much better when connection to their background is clear and hence follow much better.

• Use same notation as in lecture where possible (even if that means that it’s different from the paper (whp it will be))

• How to present a theorem: in a modular way

• After theorem statement, give intuition, potentially illustrate with examples what it is claiming

• Filter the strong assumptions from the weak. Also try to always discuss the implications of making those assumptions on the applicability of the result

• proof depends on following key ideas (lemmas) 1,2,3, which are insightful and intuitive (give rise to potential new proofs)

• If the lemmas have key insights beyond algebra that are crucial to understand where the surprise in the theorem comes from, add the proofs of lemmas afterwards

## Content and style

Note: This is mainly repeating https://www.youtube.com/watch?v=meBXuTIPJQk

• Slide flow

• Make sure the reader always knows how each slide is connected to previous slide and to the main point of the presentation

• e.g. is this now just setting it up, the actual mathematical formulation of main point, interesting extensions for different assumptions…, empirical finding?

• Connect slides with a good transition (you can use last line to make transition explicit), e.g.: Caveat: x, Next slide: y

• Summarize slide / table / plot / theorem message

• Each slide should convey one message, summarizable in a one line slide title

• Don’t number figures / tables / theorems which usually happens when you blindly copy from papers. Instead, summarize the main message in few words in brackets.

• Don’t refer to sections, claims etc from the paper by their number (e.g. “in section 7 blabla”)

• Slide style

• Only put things (figures, labels etc.) on the slides you will refer to verbally

• That will automatically cut down on slide content

• Don’t make slides too full (max 4 bullet points-ish)

• Write bullet points (see lectures)

• NEVER write a full a paragraph

• nor full sentence

• one conceptual point per line!

• Absolutely use animations whenever possible

• Reveal important blocks one at a time on one slide, e.g. different bullet points, theorems after notation, or proof sketch after going through the theorem. General rule: The less connected the points are, the more inclined you should be to reveal one at a time

• That makes sure the audience is not wondering about something on the slide you are not talking about, hence losing their attention

• For some more sophisticated study on how to exploit text on slides with what you say, please watch https://www.youtube.com/watch?v=meBXuTIPJQk