Talk:Binary heap

message: Can you guys make some pages for "k-ary heap"? 
I like this "binary heap" page, but I also wish to see some information for "k-ary heap". Thanks, everyone..
Don't want to be offensive, but the ASCII art sketch kinda sucks :) --84.57.224.246 13:12, 8 November 2005 (UTC)
thread_title:  k-ary heap 

message: I wanted to edit the page to add this, but I don't have an svg editor.
A faster method of deleting the root is to remove it and promote its larger (max-heap) or smaller (min-heap) child.  The space occupied by that child is now free, so promote one of its children, and continue recursively until the free space is pushed down to the bottom level.  Move the last element of the heap into this new free position, and then percolate it up.  
Here is an example (requiring fixed width font):
initial heap:
         15
    11         8
  3    4     5
remove root:
         __
    11         8
  3    4     5
11 > 8 so move 11 to the root:
         11
    __         8
  3    4     5
4 > 3 so move 4 up:
         11
    4          8
  3   __     5
We have reached the bottom level.
Move the last element (5) into the blank space.
         11
    4          8
  3   5     
5 > 4 so swap 5 with its parent:
         11
    5          8
  3   4     
5 < 11 so stop.
Analysis:
The algorithm which replaces the root with the last leaf requires two comparisons per level, to an average depth of log_2(n).  Because the element is a leaf, it will be pushed all the way back down to the bottom on average.  Total cost: 2*log_2(n) comparisons and log_2(n) swaps.
The algorithm above does one comparison per level to a guaranteed depth of log_2(n), followed by one comparison per level for an average of k~=1.6 levels.  Because the last element was a leaf, it does not move up the heap very far on average.  Total cost: log_2(n) + k comparisons and log_2(n)+k swaps, where k~=1.6.  It is twice as fast.
Also, above 90% of the time with heaps is spent deleting the root (insertion is O(!) on average) so the better algorithm really will make your heaps almost twice as fast. 
Another improvement:
Perhaps some budding computer science student would be willing to write this up.  
For array based algorithms, it's really better to think in terms of copies instead of swaps.  A swap requires 3 copies, but all of the algorithms above can be implemented using the same number of copies as is quoted for swaps.
Here is the example above, written as an array, with copies not swaps.
initial heap:
15 11  8  3  4  5
We have copied the root (15) and now we want to clobber it.
Copy the larger child into the root:
11 11  8  3  4  5
The second 11 is really empty space.  Clobber it with its larger child:
11  4  8  3  4  5
The second 4 is really empty space.  We need to insert 5, but we want to delay copying it until we know its final position.  To determine that, compare 5 with the parent of the "free" spot (the second 4).   The parent is the first 4.  5 > 4, so clobber the free space with 4:
11  4  8  3  4  5
Compare 5 with the parent of the free space again.
11 > 5 so we stop and copy 5 into the free space:
11  5  8  3  4  5
The last 5 is really free space, but there's no point in overwriting it.  It will be clobbered the next time something is added to the heap.
I know it looks inefficient (or at least, not better) on this small example, but recall the argument above.  This method does one comparison per level plus one or two extra comparisons on average, and the same number of copies.  On heaps with more than 3 levels it will be faster.  
I hereby release this post to the public domain.  I would be delighted if someone were to incorporate any of it into the article.  Thank you Wikipedia people for an invaluable resource. —The preceding unsigned comment was added by Roman pearce (talk • contribs) 04:07, 19 December 2006 (UTC)
thread_title:  a faster method of deleting the root 

message: quote:---
This approach is particularly useful in the heapsort algorithm, where it allows the space in the input array to be reused to store the heap. However it requires allocating the array before filling it, which makes this method not that useful in priority queues implementation, where the number of tasks (heap elements) is not necessarily known in advance.
---:endquote 
True for true arrays, but it's easy to have a 'growing' array simply by adding a redirection layer when reading and writing, and a redirection + test for more-space-required (plus, if more space required, actually alloc'ing that space).
Granted it's not an array any more, exactly, but it still resembles an array programmatically (even if it has to be addressed through functions/methods rather than [] syntax) and is very fast.
My point is not to elaborate on how to get around the problem of fixed-size arrays, just that the problem quoted isn't a problem and the mention of a 'limitation' should be removed or amended.
Thoughts?  —Preceding unsigned comment added by Water pepper (talk • contribs) 09:00, 7 January 2008 (UTC)
replies: text: Of course you can use a dynamic pseudo-array, simulated by an additional software layer. But in this case you must either re-allocate space for growing array and copy its contents, each time you need to extend it (possibly many times), OR you need a dynamic structure (some lists, trees, etc.) and search for items to be compared or swapped, every time you simulate an index addressing. Both ways impose a not acceptable overhead to the sorting routine. In fact there are dynamic structures (like lists or trees) and algorithms tailored to them, which perform as good as heapsort with arrays. So, if you need dynamic data size, use dynamic structures and appropriate algorithms. Of course it is always (well, almost always...) possible to force some algorithm for inappropriate data structure — but that is not a good programming practice. Don't force a specific algorithm just because you know it! --CiaPan (talk) 14:19, 7 January 2008 (UTC)
replies: text: Or you dangle a new heap off an element in the heap at the cost of an extra test for each operation (in any language with objects as pointers (such as python or javascript) the cost is negligible).  In my experience doing this with small blocks (say 64 entries) out performs any purely tree based approach (such as fib trees) (perhaps for cache reasons).  It also makes it trivial to merge two heaps. --Jaded-view (talk) 20:32, 27 September 2008 (UTC)
replies: text:  Note that a records-and-references implementation is not much worse than an array-based implementation. I've made a C++ implementation based on nodes with pointers to left and right children (plus the level-order node index, to allow arbitrary "erase element" and "update element priority" operations), while resolving the tree algorithmically using a parent stack. Compared to my C++ implementation based on a fixed-capacity array, the "pure tree" implementation takes almost 200% more than the array implementation for pushes (but we talk of 0.03us vs. 0.09us, approx constant with the number of elements, as expected), and a 30% more than the array implementation for popping the root (0.10us to 0.44us vs. 0.14us to 0.55us for a node count ranging from 10 to 10000). As I've written on another comment, above 1000 or 10000 nodes (depending on the payload size) the effect of cache misses dominates in both implementations. For the record, a sorted doubly-linked list implementation has comparable running time up to about 50 elements, skyrocketing for larger data sets. This was on an AMD Sempron 3200+ PC using GCC 4.3 on Debian Testing. All in all, considering that a dynamically resizable array involves copying its content on resize, I think the flexibility of a records-and-references implementation worths the little extra time for data sets of arbitrary sizes. SalvoIsaja (talk) 17:23, 18 October 2009 (UTC)
thread_title:  can use array-like structures when number of items is not known in advance 

message: Are you sure it can be done in O(n)? Cuz that means you can heapsort in O(n), which of course is impossible. I don't see any references, so someone who understands math symbols should check on that section.   —Preceding unsigned comment added by 20.132.68.146 (talk) 15:47, 27 August 2009 (UTC)
replies: text: I'm not sure what 'it' means in 'it can be done'. If you, 20.132.68.146, mean 'building a heap with a given set of n nodes (values)', as the section's title says, then yes, _it_ can be done in linear time O(n). On the other hand if you mean a heapsorting a given sequence of n values, then of course it can't be done in O(n), because the second phase of the sort alogrithm performs n 'delete root' operations, half of which may cost up to log(n)−1 swaps. --CiaPan (talk) 20:34, 12 September 2009 (UTC)
thread_title: building a heap--wtf?

message: "sift-up" ?
Possibly
"shift-up"
 —the preceding comment added 193.91.83.251 (talk) 19:39, 6 October 2009.
: Nope. See sift in Wiktionary. --CiaPan (talk) 14:30, 21 October 2009 (UTC)
thread_title:  Typo 

message: This whole section really seems out of place. Even if a mathematical justification that the formulas define a tree is appropriate in this article, I would think something simple and direct would be more appropriate than what's there. (e.g. observing that 'parent' and ('left child' and 'right child') are inverses in an appropriate sense, and maybe stating which range of indexes correspond to which levels of the tree) Anyone else agree? Hurkyl (talk) 13:49, 26 February 2012 (UTC)
thread_title:  Derivation of parent/child index formulas 

message: How can the number of nodes at height h be \le \left\lceil 2^{\left(\lg n - h\right) - 1} \right\rceil? The term  2^{\left(\lg n - h\right) - 1} is never greater than 1 for any level/height (example: h=2 \implies 2^{(\lg 3 - 2)-1} = 0.375, but there're 2 nodes at the height 2.
188.103.194.161 (talk) 20:29, 28 May 2012 (UTC)
thread_title:  Building a tree 

message: Why is search time complexity listed?  Correct me if I'm wrong, but I did not believe heaps use a search operation at all.  What would it be used for?  Heapsort doesn't use it.  Inserting wont use it (that's O(lg n) w.c.).  Etc.  Why is the time of an operation that, I thought, is irrelevant to a data structure listed?  Furthermore, the heap overview page does not list searching as an operation for heaps, nor does it list any runtimes in this table (http://en.wikipedia.org/wiki/Heap_(data_structure)#Comparison_of_theoretic_bounds_for_variants).  I'm going to remove it, as I believe it to be irrelevant information.  Accurate yes, but still an irrelevant operation for this data structure.  Unless someone can correct me?   Also there is a problem with the gadget used for listing the time complexities -- it does not allow for additional listings such as extract min time, decrease key time, etc.  How can we fix this?  Thanks  68.49.45.5 (talk) 05:51, 18 August 2012 (UTC)
thread_title: Search Time

message: min heaps used for priority queues? not max heaps?
--195.7.8.195 (talk) 6 February 2013‎
: No, not max heaps. Usually the higher priority is represented with lower numeric value, so it's min-heap which pushes high-priority items to the front of a queue. --CiaPan (talk) 00:25, 7 February 2013 (UTC)
thread_title: possible error

message: The Max-Heapify pseudo-code doesn't make any sense without an explanation of what the mysterious heap_length is. There's no concept of a heap length introduced earlier in the article. 208.54.40.174 (talk) 18:12, 14 February 2013 (UTC)
replies: text: Thanks for noticing. Fixed. --hydrox (talk) 18:26, 14 February 2013 (UTC)
thread_title: heap length?

message: Nevermind, it is correct.
Fmcoelho (talk) 22:37, 22 April 2013 (UTC)
thread_title:  Is the remove pseudo-code wrong? 

message: There was already a comment here regarding searching. The author argued that it does not make sense to list search time complexity for heaps since no search operation were defined for them.
I consider this a mistake. The thing is: The heap is a collection, and collections can be searched. Why should the heap be an exception to this rule?
Of course, the heap is not used for fast searching. But that has nothing to do with the question whether there is a search operation defined or whether it makes sense to list its search time complexity. For example, the linked list has a search time complexity of O(n). Obviously, it is not meant for searching and will not be used for that (in general). But does that mean that there is no search operation defined on linked lists or that the WP user does not want to know its search time complexity? Obviously, no.
So, in my opinion articles should always state the search time complexity for collection data structures, even if the respective collection is not meant for searching. 134.130.224.143 (talk) 08:04, 25 August 2014 (UTC)
thread_title:  Searching heaps 

message: is the use of ← for assignment really so strange that you feel you need to explain it in a comment? If so, we'd better find a new notation, like . I find the comment a bit distracting.
(Related discussion.) QVVERTYVS (hm?) 20:45, 11 August 2015 (UTC)
thread_title:  Assignment operator