Talk:Treap

message: I'm not sure the priority has to be random, even though a random priority can be used to help avoid worst-case insertions into a binary search tree. I believe that a treap resolves to a priority queue if non-random priorities are used.
If a helper function is implemented that updates the priority of a given element in the treap, then removal is as simple as updating the element to be removed's priority to MIN_VALUE, then deleting it, because it will then be a leaf Node. This may be asymptotically weaker than the canonical removal method though, due to necessary tree rotations to restore the heap property.  — Preceding unsigned comment added by 173.66.36.135 (talk) 22:58, 29 December 2013 (UTC)
replies: text: Rather than talking about what you're not sure of or what you believe, provide a source. Wikipedia is not built from the beliefs of editors. -- Jibal (talk) 06:30, 25 October 2018 (UTC)
thread_title: treap

message: In the original Aragon and Seidel paper, the illustrations showed a max heap ordering.  Since the priority of a node is randomly generated, their is a small chance that a child and a parent could have the same priority. MegaHasher 00:20, 6 August 2007 (UTC)
replies: text: I agree. I think that "max heap" (root node has highest numeric value) may be slightly easier to understand than "min heap", so I've edited the article to try to be consistent "max heap" terminology. --68.0.124.33 (talk) 18:49, 20 May 2010 (UTC)
thread_title: Min heap versus max heap

message: A majority of the Definition section looked like it was plagiarized wholesale from a webpage (apparently from 2003) at Cornell, and no attribution was given.  I removed the material and added an external link. 71.182.188.252 19:47, 4 December 2007 (UTC)
replies: text: I removed it again. We'll see whether it sticks this time. It would probably have helped to use a more detailed edit summary — a large removal of material by an anonymous user with no explanation looks at first glance a lot like vandalism, so it's easy to understand why it was reverted. —David Eppstein 20:55, 4 December 2007 (UTC)
thread_title: Plagiarized material in the Article

message: Really? I would think that, given the worst case in which the treap ends up totally unbalanced, search would be O(n). Where does the lower amortized bound come from?  — Preceding unsigned comment added by Anschelsc (talk • contribs) 06:38, 24 February 2014 (UTC)
replies: text: I don't know why they're listed as amortized, either. They should be O(\log n) expected time and O(log n) with high probability. —David Eppstein (talk) 08:11, 24 February 2014 (UTC)

text: The chance of the worst case occurring is only 1/(n!), and is independent of the data (assuming that the pseudorandom number generator is randomly seeded). Because it's independent of the data, the worst case amortized across numerous runs with the same data is O(log n). -- Jibal (talk) 06:46, 25 October 2018 (UTC)
replies: text: That's what expected case means. It's not what amortized means. —David Eppstein (talk) 07:02, 25 October 2018 (UTC)
thread_title:  Amortized O(log(n)) worst case 

message: I think the description of the merge operation in the Bulk Operations section is very unclear. I might try fixing it later. 119.85.37.175 (talk) 01:46, 10 July 2015 (UTC)
replies: text: I fixed it. Any refinements welcome. 119.85.37.175 (talk) 01:58, 10 July 2015 (UTC)
thread_title:  It's not clear how to merge treaps