<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Pairing Heaps with Costless Meld · HackerPapers discussions</title><link>https://hackerpaper.kaipfister.de/p/0903.4130/</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/0903.4130/feed.xml" rel="self" type="application/rss+xml" /><item><title>Pairing Heaps with Costless Meld — mentioned by jbapple</title><link>https://news.ycombinator.com/item?id=15225256</link><guid isPermaLink="false">urn:hackerpapers:mention:0903.4130:15225256</guid><pubDate>Tue, 12 Sep 2017 06:37:25 GMT</pubDate><description>&lt;p&gt;&amp;gt; checking for key existence is generally only amortized constant (that is to say, not constant across all lookups) What you just described is &amp;quot;average&amp;quot; not &amp;quot;amortized&amp;quot;. Amortized does not mean &amp;quot;across a set of representative inputs&amp;quot;, it means &amp;quot;through time, even if given the same input repeatedly&amp;quot;. Amortized complexity is tricky sometimes. For instance, in a data structure storing a binary integer and allowing an increment operation, the number of bits flipped is amortized O(1). The same is true if the only operation is decrement. Neither is true if you have both increment and decrement!…&lt;/p&gt;&lt;p&gt;&lt;a href="https://hackerpaper.kaipfister.de/p/0903.4130/"&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>
