<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Efficient Random Sampling -- Parallel, Vectorized, Cache-Efficient, and Online · HackerPapers discussions</title><link>https://hackerpaper.kaipfister.de/p/1610.05141/</link><description>Collected HN comments and submissions linking this paper.</description><language>en</language><lastBuildDate>Mon, 02 Nov 2026 11:16:22 GMT</lastBuildDate><atom:link href="https://hackerpaper.kaipfister.de/p/1610.05141/feed.xml" rel="self" type="application/rss+xml" /><item><title>Efficient Random Sampling -- Parallel, Vectorized, Cache-Efficient, and Online — mentioned by lorenzhs</title><link>https://news.ycombinator.com/item?id=14512903</link><guid isPermaLink="false">urn:hackerpapers:mention:1610.05141:14512903</guid><pubDate>Thu, 08 Jun 2017 09:08:40 GMT</pubDate><description>&lt;p&gt;The sampling algorithm you describe becomes pretty slow as k grows. There are much faster algorithms. We wrote a paper on fast sampling: https://arxiv.org/pdf/1610.05141.pdf (page 11, what you described is labelled &amp;quot;H&amp;quot; (for hash table) in the plot. Sorry about the single-letter names, it&amp;#x27;s a weird convention for sampling algorithms). You can see that as soon as k is more than a few thousand, &amp;quot;R&amp;quot; (&amp;quot;recursive&amp;quot;) is much faster. What it does is recursively split the range (initially 1...N) in half, and deciding how many samples come from the left and how many from the right side. It does this by…&lt;/p&gt;&lt;p&gt;&lt;a href="https://hackerpaper.kaipfister.de/p/1610.05141/"&gt;Paper and discussion history&lt;/a&gt;. A mention is not an endorsement.&lt;/p&gt;</description><category>cs.DS</category></item></channel></rss>
