Ask HN: How to read CS papers?
Inspired by https://news.ycombinator.com/item?id=13268748
My problem is going from:
Reading and understanding a paper => Implementation
Let's take a few papers as examples:
- Gorilla http://www.vldb.org/pvldb/vol8/p1816-teller.pdf
- Dremel https://static.googleusercontent.com/media/research.google.com/en//pubs/archive/36632.pdf
- Hokusai http://www.auai.org/uai2012/papers/231.pdf
I've tried to read those papers and implement some basic code, but I have no idea where to start. I've gotten so used frameworks that document each piece of the beast, as well as code to back it up, that I don't know how to understand a paper from a "conceptual" level.
This feels like a deeper skill that I'm missing. Any thoughts?
5 comments
[ 3.0 ms ] story [ 14.7 ms ] threadQuestion for you: What do you want to implement from such papers, and what do you expect to gain from doing so?
They describe on the one hand small-but-important details and on the other large-scale overviews over really complex systems. The small details are presented precisely enough so that you probably could code them relatively directly, but they aren't necessarily immediately useful. E.g. in the Gorilla paper you probably could implement their compression algorithms from what they've written there. Is that useful to you? Do you have a problem where you can apply that implementation?
The high-level overviews are interesting if you plan on writing an entire similar system, or to understand pain points in an existing one you have, but there of course is a lot of engineering and knowledge involved that is not in the paper.
I'd say papers that do not present a specific algorithm with in- and outputs you can easily deal with using what you have are not good candidates to just go from paper to implementation, and even then the paper without further context often doesn't give you all you need to do so.
I actually don't think I understand well enough.....
The high-level overviews are interesting if you plan on writing an entire similar system, or to understand pain points in an existing one you have
This seems valuable as well
I generally just don't know how to grok CS papers well. Thus, I can't say what value I expect to gain, if I'm always gaining zero value.
Wobbrock, J.O., Wilson, A.D. and Li, Y. (2007). Gestures without libraries, toolkits or training: A $1 recognizer for user interface prototypes. http://faculty.washington.edu/wobbrock/pubs/uist-07.01.pdf
They also have a great page related to that paper with actual implementations and links to works building on it: http://depts.washington.edu/madlab/proj/dollar/index.html (Otherwise it can be worthwhile to follow the citation chain on Google Scholar or other sites, at least with papers that are not cited by everybody)
Some other ideas:
There are also resources like https://blog.acolyer.org/ where papers are presented in blog-post form, reading both the paper and the reviews might help to get an eye for what you can and can not get from them.
Try to find conferences or other venues with papers from a field you know a lot about/have worked in, reading papers with understanding for the context is always easier. Many fields have "classic" papers that are often referenced and more or less required background knowledge to judge things, these are interesting to find and read as well.
I currently have a solution to try to fix this, it's still in pre-alpha stage:
www.wikipaper.org
If any HN'ers has time to help me I'd be much appreciative. This is a big problem and can't really be solved via commercial means, it can only work as an open-source project.
There's been many, many attempts to solve this problem in the past but all of them have been fairly limited in featureset & momentum. I currently have a solution to try to fix this, it's still in pre-alpha stage:
www.wikipaper.org
If any HN'ers has time to help me I'd be much appreciative. This is a big problem and can't really be solved via commercial means, it can only work as an open-source project.
There's been many, many attempts to solve this problem in the past but all of them have been fairly limited in featureset & momentum.
- The lack of an ability to print videos/animations on a piece of paper. Oftentimes, complex concepts require a graphical animation (or video) to be succinctly conveyed.
- Papers are often written in a non-native tongue.
- Overly complex words or inappropriate words to appear more sophisticated. This doesn't necessarily correspond to field jargon.
- "Filler" material added in order to meet the page count recommendation... or conversely, trying to pack too much in.
- Authors not having the mindset of explaining complex details in a straightforward format.
- The "blowing up" of simple equations in order to make them look more complex.