0

I want to merge a binary heap implemented as an array with size m into another heap (of the same kind) with n elements. Using repeated inserts, this takes O(m * log(n)). It seems to be commonly agreed that the alternative method of concatenating the arrays and then rebuilding the heap, taking O(m + n) is more efficient.

Now it seems clear to me that for some pairs (m, n) with m < n, the O(m * log(n)) method would be more efficient. According to Wolfram Alpha this is the case for m < (n * log(2)) / log(n / 2). Is this interpretation correct? And is a check worth the implementation effort/runtime-hit in practice?

Oberon
  • 3,219
  • 15
  • 30

1 Answers1

2

Your interpration is wrong. As you insert elements one by one in the first heap its size will grow, getting closer to m+n, thus the complexity each insert will no longer be O(log(n)). In fact inserting elements one by one will have complexity on the order of O(m * log(m + n)).

This make the limit for the value of m for which it is better to inserting the values from the smaller heap one by one tighter, but does not eliminate it. For instance if you have a heap of size 100000 and want to merge it with a heap of size 2, it is better to insert the two elements.

Also note there are different kinds of heaps that support merge operation with better complexity. For instance a leftist heap is easy to implement and supports merge in O(log(n)).

Ivaylo Strandjev
  • 69,226
  • 18
  • 123
  • 176
  • Ok, but doesn't that merely shift the point at which the repeated insert is more efficient? Or does it also make the check impossible/far more costly? – Oberon Apr 11 '15 at 08:35
  • Well it shifts the point kind of. Still there will be some value of M for which it is less costly to insert each element one by one. For instance if you have a heap of size 100000 and want to merge it with heap of size 2, it is better to insert the elements. I see that this is not obvious from my answer so I will add it. – Ivaylo Strandjev Apr 11 '15 at 08:38