I have a background in mathematics and I am accustomed to reading papers with lemma and proofs. When I see a deep learning paper, they seem to be of practical nature.

How can I improve my reading and understanding of deep learning papers?

To truly understand, should I have to implement the code? What is the best approach (if any)?

  • 1
    $\begingroup$ Hello, welcome to the artificial intelligence stack exchange. I feel that this question may be closed due to its subjectiveness... $\endgroup$
    – hanugm
    Commented Nov 15, 2021 at 12:24
  • $\begingroup$ In addition to the comment above and my answer, there is already a more general question here, to which I also provided a similar answer (I realize this only now). Given that the questions are not exact duplicates, I won't close yours for now. $\endgroup$
    – nbro
    Commented Nov 15, 2021 at 14:35
  • 1
    $\begingroup$ There are a lot of machine learning papers which are theoretical in nature, and their primary contribution is lemmas and theorems. There are also an immense number of papers whose contributions are based around a new equation or mathematical idea, which are supported by derivations or proofs, and have some experiments that just validate the idea. To understand such papers, you have to understand the equations and the experiments you can just quickly glance over. $\endgroup$
    – Taw
    Commented Nov 15, 2021 at 18:35

2 Answers 2


Adding something to nbro answer, from my personal experience there are also some hints that can quickly tell you if you're dealing with a good machine learning paper, i.e. worth to read in its entirety or not.

In random order:

  • Clear contribution description: machine learning and artificial intelligence in general are both broad fields. A paper can be about several things, and it should be clear already from the title what the main contribution is: a new model architecture? A new pre/post processing step? New loss function? If it's not clear after reading the abstract there are high chances that this point will not be clear also after reading the whole paper.

  • Clear architecture/algorithm description and visualization: images and code snippets make a huge difference. As you pointed out, machine learning is mostly an applied field, hence having a code snippet or a clear list of implementation passages reduce the overhead of thinking about how to turn into code the math in an efficient way, and it also reduces the chances of making interpretation mistakes when the passages are not clear or give for granted. Since you're from a mathematical background you are probably experiencing the opposite feeling and wondering why there's not that much math inside. Point is that most machine learning papers are structured like experimental papers. You have hypotheses, not theorems to prove, you run experiments to test them and you describe the results at the end.

  • Code availability: unfortunately, still not such a common practice, making your code available is fundamental, not to make other people's life easier, but to grantee the reproducibility of the published results. Moreover, machine learning is characterized by many subtle and arbitrary choices, especially when it comes to hyperparameters, which are many times not reported on the real papers, and, when that's the case, looking at the code becomes the last resource to find that information.

  • Proper benchmarking: evaluating the impact of a new loss/architecture is always hard. Many papers just report tables with random scores like "97% accuracy", which means nothing when not compared to other models. A good paper always reports the state of the art (SOTA) scores and test the proposed improvements ON EXACTLY THE SAME DATA. Furthermore, a paper ideally should report mean scores over several training runs. Unfortunately, due to the expensive hardware and long time required to train only a single model, this is almost never done.

  • Short but clear SOTA analysis: it is super hard to stay on track with the state of the art when it comes to machine learning, since dozens of papers are published every month. For this reason, the literature research section should be concise and point to works that are as closest as possible to what is going to be described (and improved upon) in the paper, otherwise, you know you're reading a survey instead.


I have some experience reading research papers. However, in my view, there is no single answer to this question (apart from this answer I am giving you, i.e. "it depends"). The answer to your question depends on

  1. your background knowledge/education

    • If you don't know much about the specific topic in the paper, you may need to study at least briefly the prerequisites for reading the paper, otherwise, you won't understand much about the paper.
  2. why you are reading the paper

    • Are you just interested in or curious about the topic in the paper? Then maybe you can only quickly read it, or only read specific sections, such as the ones that introduce the technique (abstract, introduction, and maybe conclusion) and skip all the math; the figures are sometimes also insightful.

    • Are you doing (serious) research on a related topic? If yes, you will probably need to read the paper multiple times (at least the sections that you don't fully understand). It may also be useful to look at implementations of the approach. If they don't exist, you may consider implementing the approach yourself.

    • Do you need to present the paper? In this case, you may also need to read the paper multiple times, understand well the figures (because you will probably use them in your slides: an image is worth 1000 words, etc.)

  3. how much time you have to read the paper

Note that these guidelines should also be applicable to other cases (i.e. when you're reading other types of research papers that involve math).

You may also be interested in the paper How to Read a Paper (by Keshav). It provides a few tips that could be useful.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .