Abstract
Heaps, or priority queues, are collections of elements from an ordered set where besides checking for emptiness and inserting elements.
This is a preview of subscription content, log in via an institution.
Buying options
Tax calculation will be finalised at checkout
Purchases are for personal use only
Learn about institutional subscriptionsNotes
- 1.
I will implement all the heaps in this chapter to have access to the minimal element. It is a trivial modification to have access to the largest instead.
- 2.
I am being a little lax with notation here. We cannot sum to log(n) unless this is an integer, and strictly speaking it should be ⌊log(n)⌋. This doesn’t change the complexity analysis and I just don’t feel like being too strict with the mathematics in a book that is primarily about R programming.
- 3.
My description of leftist heaps is based on Okasaki (1999a). The original description of the data structure can be found in Crane (1972).
- 4.
The smaller half name is an oxymoron. If we really split data in half, both halves would be the same size. What we really mean is that we slice away at least one half of the data in each recursion. I didn’t come up with the name, but that is the name I know the trick by.
- 5.
If someone inserts NA into a heap, this would break, of course, but then if someone does that they should have his head examined. With NA there is no ordering, so the whole purpose of having a priority queue goes out the window.
- 6.
Using NULL to represent empty trees is a straightforward solution, but it does add some extra danger to working with the trees. In R, if you access a named value in a list that isn’t actually in the list, you will get NULL back. This means, for example, that if you misspell a variable, say write x$lfet instead of x$left, you will not get any complaints when running the code, but you will always get NULL instead of what the real left subtree might be. Interpreting the default value when you have made an error as a meaningful representation of an empty tree is risky. We have to be extra careful when we do it.
- 7.
For a full splay tree implementation, we will also modify trees when we search in them. For the heap variant, where we explicitly store the minimal value, we do not need to do this, so for the splay heap, we only modify trees when we insert or remove from them.
- 8.
Proving this is mostly an exercise in arithmetic, and I will not repeat this analysis here. If you are interested, you can check Okasaki (1999a) or any text book describing splay trees.
- 9.
If performance becomes enough of a problem that the long version of partition is needed, that performance is probably better achieved by moving some of the code to C/C++ than by having the complicated partition function.
Author information
Authors and Affiliations
Rights and permissions
Copyright information
© 2017 Thomas Mailund
About this chapter
Cite this chapter
Mailund, T. (2017). Heaps. In: Functional Data Structures in R. Apress, Berkeley, CA. https://doi.org/10.1007/978-1-4842-3144-9_5
Download citation
DOI: https://doi.org/10.1007/978-1-4842-3144-9_5
Published:
Publisher Name: Apress, Berkeley, CA
Print ISBN: 978-1-4842-3143-2
Online ISBN: 978-1-4842-3144-9
eBook Packages: Professional and Applied ComputingApress Access BooksProfessional and Applied Computing (R0)