Consider two min-heaps H1,H2 of size n1 and n2 respectively, such that every node in H2 is greater than every node of H1.
How can I merge this two heaps into one heap "H" , in O(n2) (not O(n^2)..)?
(Assume that the heaps represented in arrays of size > n1+n2)
A heap can be constucted in linear time see here. This means you need only take all elements and construct a heap from all the elements to get linear complexity. However you can use a "more fancy" heap for instance leftist heap and perform the merge operation even faster.
Related
Let H1 and H2 be two complete binary trees that are heaps as well. Assume H1 and H2 are max-heaps, each of size n .Design and analyse an efficient algorithm to merge H1 and H2 to a new max-heap H of size 2n.
==========================================================================
Approach - First copy the two arrays of H1 and H2 into a new array of size 2n...then apply build heap operation to get H...Time complexity=O(2n)=O(n), but doesn't need we need to apply Max heapify after building the heap? So, where's O(logn) time considered for that.
===================================================================
Another approach says merging two max heaps takes O(n+m) time. Now, what's correct and why no one is caring for Max Heapify?
MaxHeapify operation takes O(logn) time.
In Build Heap Operation, we need to call MaxHeapify n times. Therefore it seems that total complexity of build heap operation is O(nlogn)
But it is not correct. Actually build heap operation takes only O(n) time.You can refer this link to get idea about it.
https://www.geeksforgeeks.org/time-complexity-of-building-a-heap/
Hence it takes O(2n) => O(n) time complexity to build new heap H of size 2n.
If you consider two max heaps of size m and n, it takes O(m+n) time complexity to build new heap of size m+n.
I want to Find Maximum number of comparison when convert min-heap to max-heap with n node. i think convert min-heap to max-heap with O(n). it means there is no way and re-create the heap.
As a crude lower bound, given a tree with the (min- or max-) heap property, we have no prior idea about how the values at the leaves compare to one another. In a max heap, the values at the leaves all may be less than all values at the interior nodes. If the heap has the topology of a complete binary tree, then even finding the min requires at least roughly n/2 comparisons, where n is the number of tree nodes.
If you have a min-heap of known size then you can create a binary max-heap of its elements by filling an array from back to front with the values obtained by iteratively deleting the root node from the min-heap until it is exhausted. Under some circumstances this can even be done in place. Using the rule that the root node is element 0 and the children of node i are elements 2i and 2i+1, the (max-) heap condition will automatically be satisfied for the heap represented by the new array.
Each deletion from a min-heap of size m requires up to log(m) element comparisons to restore the heap condition, however. I think that adds up to O(n log n) comparisons for the whole job. I am doubtful that you can do it any with any lower complexity without adding conditions. In particular, if you do not perform genuine heap deletions (incurring the cost of restoring the heap condition), then I think you incur comparable additional costs to ensure that you end up with a heap in the end.
how can I merge two heap arrays into one balanced heap array and still maintain linear complexity? Much of the material I read about merging heaps takes O(nlogn).
There is an O(n)-time algorithm (sometimes called "heapify") that, given n total values, creates a max-heap from those values. This earlier answer describes the algorithm and explains its runtime. You can use this algorithm to merge two max-heaps by creating a new array storing all the values from those max-heaps and applying the heapify algorithm to construct an new heap out of them.
If you know you'll be merging heaps frequently, though, there are better data structures than binary heaps. For example, binomial heaps, pairing heaps, and skew heaps all support melding in O(log n) time.
Hope this helps!
We are given two heaps of size N each. Each heap can be represented as an array See relation between parent and child. So we have two arrays which are heap ordered. We need to concatenate these two arrays into one by adding all the elements of one array to the end of the other.
So now we have one array of size 2N but it is not heap ordered. To make an array heap ordered it takes linear number of compares and hence takes linear time. (See bottom-up heap construction - Order of building a heap in O(n))
Can someone explain why the following algorithm for merging heaps isn't correct?
Lets say we have two (max) heaps H1 and H2.
To merge them:
create an artificial dummy node whose key value is negative infinity and place it at the root with H1 and H2 attached as children. Then do an O(log n) bubble down step that swaps the root eventually to a leaf position, where it is ultimately deleted. The resulting structure is a merged heap.
I have seen claims both on wikipedia and elsewhere that merging two equal sized heaps is a Theta(n) operation, in contradiction with what I've written above.
At least as heaps are normally implemented (with the links implicit in the placement of the nodes), a part you seem to be almost ignoring ("with H1 and H2 attached as children") has linear complexity by itself.
As a heap is normally implemented, you have a linear collection (e.g., an array) where each element N has elements 2N and 2N+1 as its children (e.g., with a 1-based array, the children of element 1 are elements 2 and 3, and the children of element 2 are 4 and 5). Therefore, you need to interleave the elements from the two heaps before we get to the starting point for your merge operation.
If you started with explicitly linked binary trees (just following heap-style rules instead of, for example, binary-search tree ordering) then you'd be right, the merge can be done with logarithmic complexity -- but I doubt that original article intends to refer to that kind of structure.
If you are implementing it as a tree your solution is correct. But as Jerry mentioned, merging array based heaps cannot be done in sub-linear time.
Depending on the frequency and size of the merge I suggest you use a virtual heap. You can implement it as heap of heaps (with arrays). After a few merges you can lazily merge multiple internal heaps into one large heap.
Is there an efficient algorithm for merging 2 max-heaps that are stored as arrays?
It depends on what the type of the heap is.
If it's a standard heap where every node has up to two children and which gets filled up that the leaves are on a maximum of two different rows, you cannot get better than O(n) for merge.
Just put the two arrays together and create a new heap out of them which takes O(n).
For better merging performance, you could use another heap variant like a Fibonacci-Heap which can merge in O(1) amortized.
Update:
Note that it is worse to insert all elements of the first heap one by one to the second heap or vice versa since an insertion takes O(log(n)).
As your comment states, you don't seem to know how the heap is optimally built in the beginning (again for a standard binary heap)
Create an array and put in the elements of both heaps in some arbitrary order
now start at the lowest level. The lowest level contains trivial max-heaps of size 1 so this level is done
move a level up. When the heap condition of one of the "sub-heap"s gets violated, swap the root of the "sub-heap" with it's bigger child. Afterwards, level 2 is done
move to level 3. When the heap condition gets violated, process as before. Swap it down with it's bigger child and process recursively until everything matches up to level 3
...
when you reach the top, you created a new heap in O(n).
I omit a proof here but you can explain this since you have done most of the heap on the bottom levels where you didn't have to swap much content to re-establish the heap condition. You have operated on much smaller "sub heaps" which is much better than what you would do if you would insert every element into one of the heaps => then, you willoperate every time on the whole heap which takes O(n) every time.
Update 2: A binomial heap allows merging in O(log(n)) and would conform to your O(log(n)^2) requirement.
Two binary heaps of sizes n and k can be merged in O(log n * log k) comparisons. See
Jörg-R. Sack and Thomas Strothotte, An algorithm for merging heaps, Acta Informatica 22 (1985), 172-186.
I think what you're looking for in this case is a Binomial Heap.
A binomial heap is a collection of binomial trees, a member of the merge-able heap family. The worst-case running time for a union (merge) on 2+ binomial heaps with n total items in the heaps is O(lg n).
See http://en.wikipedia.org/wiki/Binomial_heap for more information.