
Ask HN: How to read CS papers? - misterbowfinger
Inspired by https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=13268748<p>My problem is going from:<p>Reading and understanding a paper =&gt; Implementation<p>Let&#x27;s take a few papers as examples:<p>- Gorilla http:&#x2F;&#x2F;www.vldb.org&#x2F;pvldb&#x2F;vol8&#x2F;p1816-teller.pdf<p>- Dremel https:&#x2F;&#x2F;static.googleusercontent.com&#x2F;media&#x2F;research.google.com&#x2F;en&#x2F;&#x2F;pubs&#x2F;archive&#x2F;36632.pdf<p>- Hokusai http:&#x2F;&#x2F;www.auai.org&#x2F;uai2012&#x2F;papers&#x2F;231.pdf<p>I&#x27;ve tried to read those papers and implement some basic code, but I have no idea where to start. I&#x27;ve gotten so used frameworks that document each piece of the beast, as well as code to back it up, that I don&#x27;t know how to understand a paper from a &quot;conceptual&quot; level.<p>This feels like a deeper skill that I&#x27;m missing. Any thoughts?
======
detaro
(I might be totally misunderstanding where you are coming from, but...)

Question 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.

~~~
misterbowfinger
_E.g. in the Gorilla paper you probably could implement their compression
algorithms from what they 've written there_

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.

~~~
detaro
I just remembered one of the more accessible papers I've looked at in the
past, which might be interesting even if you are not familiar with the
subfield (which is a big thing with reading "random" papers, context is often
required):

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](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](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/](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.

------
WikiPaperGuy
Research papers are insanely hard to read.

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.

~~~
WikiPaperGuy
Here's the list:

\- 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.

