1 / 24

The Post-Order Heap

The Post-Order Heap. Nick Harvey & Kevin Zatloukal. Binary Heap Review. Simple p riority queue “Heap-ordered”: parent key < children keys Insert , DeleteMin require O(log n) time. keys. 1. 3. 5. 12. 9. 11. 7. …. 15. 13. 18. 20. 12. 23. Binary Heap Review.

zion
Download Presentation

The Post-Order Heap

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. The Post-Order Heap Nick Harvey & Kevin Zatloukal

  2. Binary Heap Review • Simple priority queue • “Heap-ordered”: parent key < children keys • Insert, DeleteMinrequire O(log n) time keys 1 3 5 12 9 11 7 … 15 13 18 20 12 23

  3. Binary Heap Review • “Implicit”: stored in array with no pointers • Array index given by level-order traversal array indices 1 Implicittree structure: 2 3 4 5 6 7 … 8 9 10 11 12 13 … Array: 1 2 3 4 5 6 7 8 9 10 11 12 13

  4. The Heapify Operation fix order • Combine 2 trees of height h + new root • Fix up heap-ordering • Produces tree of height h+1 • Time: O(h) +  

  5. The BuildHeap Operation • Batch insert of n elements • Initially n/2 trees of height 0 • Repeatedly Heapify to get: • n/4 trees of height 1 • n/8 trees of height 2 … • Total time:   

  6. The FUN begins… • BuildHeap: O(n) batch insert of n elements. Cannot FindMin efficiently until done. • Is O(1) Insert possible? Yes: • Fibonacci Heaps • Implicit Binomial Queues (Carlsson et al. ’88) • Is there a simple variant of binary heap with O(1) Insert? Yes: • The Post-Order Heap

  7. FindMin during BuildHeap • During BuildHeap, a FindMin is slow • Many small trees  must search for min • But BuildHeap can heapify in other orders • “Children before parents” sufficient • Idea: Change order to reduce # trees! min?

  8. O(logn) trees 7 3 6 10 8 9 11 12 A Better Ordering • BuildHeap: new node either parent or leaf • Parent is good  reduces # trees by 1 • Idea: add parent whenever possible 1 2 4 5 • This is a Post-Order insertion order

  9. Insert • Insert: • Run BuildHeap incrementally • Insertion order = post-order

  10. FindMin & DeleteMin • FindMin • Enumerate the log n roots • O(log n) time (assumingenumeration is easy) • DeleteMin: like binary heap • Find min, swap it with last element • Heapify to fix up heap order • O(log n) time

  11. Insert Analysis • Potential function  = Sum of tree heights • Insert leaf • 0 comparisons,  unchanged • Insert parent at height h • h comparisons for heapify • Decrease in  = 2(h-1) - h = h - 2  Amortized cost = 2 • Total time: O(1) amortized

  12. Expand and Contract! No Don,Potential Functions! Fun with Sums • Write BuildHeap sum as • How can we evaluate this exactly?

  13. Fun with Sums • How can we evaluate exactly? • Consider BuildHeap with n = 2k+1 - 1 • The 2k leafs pay €0 • The 2k - 1 internal nodes pay €2 • Potential at end is k (height of final heap) • Consider BuildHeap with n = 2k+1 - 1 • The 2k leafs pay $0 • The 2k - 1 internal nodes pay $2 • Total = 2k+1 - 2 - k

  14. Back to Post-Order Heaps • Problem: Array sparse  not implicit • Why? Tree-array map = level-order Insertion order = post-order • Solution: use post-order for tree-array map Tree: Array:

  15. 7 3 6 10 8 9 11 12 Navigating with Post-Order where are the children? • For node x at height h • Right child = x - 1 • Left child = x - 1 - (size of right subtree)= x - 2h • Must know height to navigate! x ? ? 1 2 4 5

  16. x+1 height h x+1 Height of New Nodes • Where is node x+1? x • 1) x is left child  x+1 is leaf  height 0 • 2) x is right child  x+1 is parent  height h+1 • Must know ancestry to update height!

  17. z … … 0 0 0 1 0 h zero bits y = left child x = right child Ancestry String • For node x at height h: • Bits below h are 0 • ith bit describes x’s ancestor at height i 0 = left child, 1 = right child … y x height h

  18. x’s ancestry string: height h … … … … 0 0 0 0 0 0 1 0 x = left child no ancestors y x x+1’s ancestry string: x+1 y = right child all left children Updating Ancestry String • One ancestry string, for last node in heap • Must update after Insert

  19. x’s ancestry string: x+1 … … … … 0 0 0 0 0 0 0 1 x = right child no ancestors x+1’s ancestry string: no ancestors Updating Ancestry String • One ancestry string, for last node in heap • Must update after Insert height h x

  20. Updating Ancestry String • One ancestry string, for last node in heap • Must update after Insert • O(1) time • Must update after DeleteMin • Easy to do in O(log n) time

  21. Problem Solution Too many trees Post-order insertion order Not implicit Post-order tree-array map Need height to navigate Maintain height for last node Updating height Maintain ancestry string Recap: Problems & Solutions • Main idea: Do Insert by incremental BuildHeap

  22. Pseudocode enumerate roots find children height & ancestry bookkeeping

  23. Experiments • 1 million Inserts (300 times): • Post-Order Heap • improves worst-case • reduces # comparisons • larger constant factor due to bookkeeping Post-Order Heap Binary Heap

  24. Summary • Potential function analysis of BuildHeap • Post-Order Heaps: • Implicit: O(1) extra space • Insert: O(1) amortized time • DeleteMin: O(log n) time • Simple, practical and FUN!

More Related