[HN Gopher] How to (seriously) read a scientific paper (2016)
___________________________________________________________________
How to (seriously) read a scientific paper (2016)
Author : sebg
Score : 32 points
Date : 2024-02-08 20:41 UTC (2 hours ago)
(HTM) web link (www.science.org)
(TXT) w3m dump (www.science.org)
| amelius wrote:
| Still waiting for an open discussion forum for scientific papers.
|
| Like StackOverflow, but every post is a paper. And there are
| experts of various gradations that help with questions.
| user_7832 wrote:
| I think researchgate tried to do that, but I don't know how
| successful they've been.
| roh26it wrote:
| Individual subreddits have usually been my go-to place to
| discuss and understand the nuances of academic papers. Love
| LocalLLama for discussions on generative AI papers.
| thsksbd wrote:
| There's too many paper
| maCDzP wrote:
| Like this? https://gotit.pub/
| shannonnn wrote:
| I'm playing around with something similar here
| https://thetrecs.com/ . But no experts yet. Even though I do
| science, I have a hard time understanding abstracts from
| adjacent fields so I'm using llms to make the abstracts easier
| for me and my friends to understand
| paulpauper wrote:
| It would be quickly overwhelmed, especially for complicated
| math papers
| wolverine876 wrote:
| Better yet (IMHO), like HN. In my field, I know where to find
| papers, etc. I'm interested in other fields, and not every
| paper; just rank them by a HN-like algorithm.
|
| I said a few days ago, in my dream HN would be mostly papers.
| That's where the richest, most accurate, most intellectually
| curious information is - far beyond most things on HN.
| AlotOfReading wrote:
| This misses the best skimming trick I learned from an advisor:
| After you read the abstract, read the last couple
| lines/paragraphs of the introduction. That's where you'll find
| the authors best summary of the paper's contributions and
| novelty. For instance, the first paper that popped up with some
| random search terms [0]: The present paper
| attempts to provide a structured and comprehensive overview of
| state-of-the-art automated driving related hardware-software
| practices. [...] The aim of this paper is to fill this gap in the
| literature with a thorough survey. The remainder of
| this paper is written in eight sections. Section II is an
| overview [...] Details [...] are given in Section III. Section IV
| presents [...] etc.
|
| When you have a meter high stack of papers for your lit review,
| comprehending long introductions and conclusions gets too
| expensive. You want to filter the irrelevant stuff as quickly as
| possible so you can spend time focused on the couple hundred
| papers you might actually read and cite.
|
| [0] https://doi.org/10.1109/ACCESS.2020.2983149
| ziddoap wrote:
| Maybe I'm misunderstanding what you mean, but I don't think
| your trick was missed at all?
|
| The second paragraph says:
|
| > _I start by reading the abstract. Then, I skim the
| introduction [...]_
|
| A few paragraphs down, another quote says:
|
| > _I always start with title and abstract. [...] I then read
| the introduction [...]_
|
| Another:
|
| > _I nearly always read the abstract first [...] I generally
| skim the introduction, reading its last paragraph_
|
| Is there something significantly different about what you are
| suggesting?
| timr wrote:
| Maybe it depends on the literature. I almost never read the
| introduction, unless I am unclear on the motivation from the
| abstract.
|
| The fundamental problem with abstracts and introductions is
| that they're _sales content_. You can 't trust them. The only
| thing you can do is decide if you wish to read further, and see
| if the paper says what they claim it says. For that, an
| abstract is sufficient about 99% of the time.
|
| For what it's worth, the proportion of papers where the body
| doesn't support the claims in the abstract is...high. Like way
| above 50%, in my experience (approaching nearly 100% for any
| random paper you find on HN or X.)
| forrestthewoods wrote:
| 1. Read the abstract
|
| 2. Read the last paragraph of the intro
|
| 3. Read the first paragraph of the conclusion
|
| 4. Read any diagrams or figures
|
| 5. Inspect the citations
|
| 6. If all else fails, read the paper itself
| dang wrote:
| Related:
|
| _How to seriously read a scientific paper_ -
| https://news.ycombinator.com/item?id=24986727 - Nov 2020 (90
| comments)
| bee_rider wrote:
| I think it really depends on where in your career you are? Like
| if you are near the beginning:
|
| * read the whole intro, make sure to look up any parts of the
| problem description you don't understand
|
| * at least skim the body of the work. If you are trying to
| implement a code, make sure to understand all the algorithm
| blocks and note how each one corresponds to the overall work so
| you don't end up implementing a special case.
|
| * read pay extra attention to the conclusion and skim the results
|
| If you are experienced, I guess you don't need advice, but I
| figure it is something like:
|
| * skim the first couple sentences (for the problem) and the
| conclusion of the intro
|
| * skip to the results section to see if the person is screwing
| you around with gamed metrics
|
| * go back if it looks good and skim their ideas
___________________________________________________________________
(page generated 2024-02-08 23:00 UTC)