Editing Binary heap

Jump to: navigation, search

Warning: You are not logged in. Your IP address will be publicly visible if you make any edits. If you log in or create an account, your edits will be attributed to your username, along with other benefits.

The edit can be undone. Please check the comparison below to verify that this is what you want to do, and then save the changes below to finish undoing the edit.
Latest revision Your text
Line 33: Line 33:
 
==Analysis==
 
==Analysis==
 
We use the fact that the height of a binary heap with <math>N</math> nodes is <math>h = \lceil \log_2(N+1) \rceil - 1 \approx \log_2 N</math>.
 
We use the fact that the height of a binary heap with <math>N</math> nodes is <math>h = \lceil \log_2(N+1) \rceil - 1 \approx \log_2 N</math>.
 
Average-case analyses are difficult, as they make assumptions about the likely distribution of keys to be inserted as well as the distribution of keys that are already ''in'' the heap. The analyses given below are not rigorous.
 
  
 
===Finding the maximum===
 
===Finding the maximum===
Line 40: Line 38:
  
 
===Insertion===
 
===Insertion===
A bottom-up heapification, in the worst case, uses approximately <math>\log_2 N</math> swaps (if it goes all the way up to the top of the tree), each of which is assumed to take constant time, giving <math>O(\log N)</math>. However, on average, the newly inserted element does not travel very far up the tree. In particular, assuming a uniform distribution of keys, it has a one-half chance of being greater than its parent; it has a one-half chance of being greater than its grandparent given that it is greater than its parent; it has a one-half chance of being greater than its great-grandparent given that it is greater than its parent, and so on, so that the expected number of swaps is <math>\frac{1}{2} + \frac{1}{4} + \frac{1}{8} + \frac{1}{16} + ... = 1</math>, so that in the average case insertion takes constant time, <math>O(1)</math> (and the expected final depth of the node is <math>h-1</math>).
+
A bottom-up heapification, in the worst case, uses approximately <math>\log_2 N</math> swaps (if it goes all the way up to the top of the tree), each of which is assumed to take constant time, giving <math>O(\log N)</math>. However, on average, the newly inserted element does not travel very far up the tree. In particular, assuming a uniform distribution of keys, it has a one-half chance of being greater than its parent; it has a one-half chance of being greater than its grandparent given that it is greater than its parent; it has a one-half chance of being greater than its great-grandparent given that it is greater than its parent, and so on, so that the expected number of swaps is <math>\frac{1}{2} + \frac{2}{4} + \frac{3}{8} + \frac{4}{16} + ...</math>, an arithmetico-geometric series that converges to 2, so that in the average case insertion takes constant time, <math>O(1)</math> (and the expected final depth of the node is <math>h-2</math>.
 
+
(A madly handwaving way to reach the same conclusion is to claim that the newly inserted node has an equal probability of ending up anywhere in the heap, so the average final depth is about <math>(1/2)h + (1/4)(h-1) + (1/8)(h-2) + ... \approx h-1</math> since about half the nodes in a complete binary tree are on the bottom level, about a quarter are on the level above that, and so on. Obviously, this premise is false, but it gives the same result.)
+
  
 
===Deletion===
 
===Deletion===
A top-down heapification, in the worst case, uses approximately <math>\log_2 N</math> swaps (if it goes all the way back down to the bottom of the tree), each of which is assumed to take constant time, giving <math>O(\log N)</math> time. In the average case, the analysis is more complicated. Assume, for simplicity, uniform distribution of keys and assume that no two keys are equal. Consider the path from the root to the now vacated original position of the key that now occupies the root. As long as the key stays on this path, it will have to be swapped down further, because we know it is less than its child on the path, but as soon as the key leaves the path, it finds itself among a subtree of keys whose sizes relative to it are unknown and uniformly distributed. The expected final depth will then be <math>h-1</math>, as in the insertion analysis. So we find that the overall expected final depth is <math>\frac{1}{2}(h-1) + \frac{1}{4}(h-1) + \frac{1}{8}(h-1) + ... = h-1</math> (where the first term corresponds to the key leaving the path on the first swap, the second the second swap, and so on). Thus, on average, <math>h-1</math> swaps occur, so the average-case time for deletion is no better asymptotically than the worst-case time.
+
A top-down heapification, in the worst case, uses approximately <math>\log_2 N</math> swaps (if it goes all the way back down to the bottom of the tree), each of which is assumed to take constant time, giving <math>O(\log N)</math> time. In the average case, the analysis is more complicated. Assume, for simplicity, uniform distribution of keys and assume that no two keys are equal. Consider the path from the root to the now vacated original position of the key that now occupies the root. As long as the key stays on this path, it will have to be swapped down further, because we know it is less than its child on the path, but as soon as the key leaves the path, it finds itself among a subtree of keys whose sizes relative to it are unknown and uniformly distributed. The expected final depth will then be <math>h-2</math>, as in the insertion analysis. So we find that the overall expected final depth is <math>\frac{1}{2}(h-2) + \frac{1}{4}(h-2) + \frac{1}{8}(h-2) + ... = h-2</math> (where the first term corresponds to the key leaving the path on the first swap, the second the second swap, and so on). Thus, on average, <math>h-2</math> swaps occur, so the average-case time for deletion is no better asymptotically than the worst-case time.
  
 
===Increasing a key===
 
===Increasing a key===
Line 56: Line 52:
  
 
==Implementation==
 
==Implementation==
A binary heap is almost always implemented using an [[array]]. Generally the root is placed at index one of the array, and if an element is placed at index <math>k</math>, then its left child is placed at <math>2k</math> and its right at <math>2k+1</math>. Using this system, the root's left child goes at index 2, the root's right child at 3, the root's left child's left child at 4, and so on; indices from <math>2^n</math> to <math>2^{n+1}-1</math> are occupied by elements of depth <math>n</math>, and no space is wasted.
+
A binary heap is almost always implemented using an [[array]]. Generally the root is placed at index zero of the array, and if an element is placed at index <math>k</math>, then its left child is placed at <math>2k</math> and its right at <math>2k+1</math>. Using this system, the root's left child goes at index 2, the root's right child at 3, the root's left child's left child at 4, and so on; indices from <math>2^n</math> to <math>2^{n+1}-1</math> are occupied by elements of depth <math>n</math>, and no space is wasted.
  
 
[[Category:Pages needing diagrams]]
 
[[Category:Pages needing diagrams]]
[[Category:Pages needing code]]
 
[[Category:Heaps]]
 
[[Category:Data structures]]
 

Please note that all contributions to PEGWiki are considered to be released under the Attribution 3.0 Unported (see PEGWiki:Copyrights for details). If you do not want your writing to be edited mercilessly and redistributed at will, then do not submit it here.
You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource. Do not submit copyrighted work without permission!

Cancel | Editing help (opens in new window)