GATE2014-2-38

Question

Suppose $P, Q, R, S, T$ are sorted sequences having lengths $20, 24, 30, 35, 50$ respectively. They are to be merged into a single sequence by merging together two sequences at a time. The number of comparisons that will be needed in the worst case by the optimal algorithm for doing this is ____.

Comments

what does optimal algorithm mean here?

---

what does worst case mean and how can we find it?

---

>optimal algorithm

means one of the best algorithm.

worst case

> kind of upper bound (means given any input algo. will not take more time then worst case)

Answer 1

The optimal algorithm always chooses the smallest sequences for merging.

$20 \ 24 -44, 43$ comparisons
$30 \ 35 -65, 64$ comparisons
$44 \ 50 -94, 93$ comparisons
$65 \ 94 -159, 158$ comparisons

so, totally $43 + 64 + 93 + 158 = 358$ comparisons.

PS: In merge operation we do a comparison of two elements and put one element in the sorted output array. So, every comparison produces one output element. But for the last element we won't need a comparison and we simply insert it to the output array. So for $n$ output elements we need $(n-1)$ comparisons.

Comments

why we are subtracting 1 from all comparisons

---

In merge operation we do a comparison of two elements and put one element in the sorted output array. So, every comparison produces one output element. But for the last element we won't need a comparison and we simply insert it to the output array. So for n output elements we need (n-1) comparisons.

---

But Sir in  merge procedure in the two lists we are putting 2 infinities/large numbers at the end.

1 3 5 999 2 4 999

Here after 4 comparisons,the  1 2 3 4 comes down into the final array.lastly to copy 5 into the final array we do compare it 999 in the second list,

---

@Arjun sir here two possibilities are there
[A]   20 24 ->44, 43 comparisons 
       30 35 ->65, 64 comparisons 
       44 50 ->94, 93 comparisons 
       65 94 ->159, 158 comparisons 

totally 43 + 64 + 93 + 158 = 358 comparisons.

---

[B]  20 24 ->44, 43 comparisons 
      30 35 ->65, 64 comparisons 
      44 65 -109, 108comparisons 
     109 50-159, 158 comparisons

totally 43+64+108+158 =373 comaprisions.       // shouldn't we keep same order as per question P,Q,R,S,T 

and question asked comaprison will be needed in worst case by optimal algorithm,

---

If the algorithm does like that it is no longer optimal. There is no need to keep any order unless explicitly mentioned.

---

okay, got it thanks :)

---

@Arjun Sir how the program will know that it is the last element of list without seeing Infinity on list..

suppose we have two list

1st list  contain 2,3

2nd list containn 4,5,6

1st  comparison of (2,4)  ----------->2 will come in Final Array

2nd comparison of (3,4) ----------->3 will come in Final Array

3rd comparison of (infinity, 4)----------->4 will come in Final Array

4th comparison of (infinity,5)----------->5 will come in Final Array

5th comparison of (infinity,6)----------->6 will come in Final Array

According to u 4 comparison will be needed but how when we compare infinity to 5 then how it will know that next element of 2nd list will be end element of the list

---

Excellent question
Excellent ans

---

@Arjun Sir,  Here we do need a min heap to select the two smallest element every time and after merging them we do need to put them backin the min heap. What about the comparisions needed to maintain the min heap? Dont we need to count them?

---

what is the best case number of comparisons performed by optimal algorithm to do the merging in above question?

---

The answer is

---

How do we know it is the last element? For that somewhere in the program we will compare (say loop until i<(n-1)) right? Won't that comparison be counted? Please solve my doubt. Thank You.

---

why total comparison -1, can you show example please..

---

Hello sir, i have never read anywhere to merge two sorted lists which are smaller in size of all the given lists, this looks like more of hamilton path instead of merge procedure. Also i have a doubt when to use two-way merge sort and when to apply merge sort algorithm like explained by @Richa bhardwaj the above comments

It will be good if can have a reference to read from clearing this doubt as nothing is talked about 2-way mergin in Coreman

---

I have the same doubt. Someone please clarify

---

you can see here he explained so well

---

@aman.anand 

My dear friend , why you are comparing with infinity ?

We know the lower and upper limits, once the one of the two array exhausted, we simply copy the remaining array.

---

@Richa Bhardwaj

this is not the right way of making an optimal tree.Maybe you got a correct answer in this case.For tree to be optimal we have to use greedy method.Hence after selecting (20 24) which equal to be 44 you should select (30 35) as it is another minimum pair.

Answer 2

To merge two lists of size m and n, we need to do m+n-1 comparisons in worst case. Since we need to merge 2 at a time, the optimal strategy would be to take smallest size lists first. The reason for picking smallest two items is to carry minimum items for repetition in merging. We first merge 20 and 24 and get a list of 44 using 43 worst case comparisons. Then we merge 30 and 35 into a list of 65 using 64 worst case comparisons. Then we merge 50 and 44 into a list of 94 using 93 comparisons. Finally we merge 94 and 65 using 158 comparisons. So total number of comparisons is 43 + 64 + 93 + 158 which is 358. 

Comments

Yes we can solve it using Huffman coding easily.

Answer 3

Solution: 158+64+93+43=358

Comments

Is it perfect method? Calculating movement and subtracting it by 1 on each parental node will give number of comparison. Will it work everywhere?

Answer 4

Merging two sorted array of m & n elents take m+n-1 in worst case .. I used this approach but I want to verify it will work for all or not work always or not?

Comments

nice solution

Answer 5

ans is 267

Comments

How? Please provide explanation also.

---

@ Taniya Mathur can u plz explain.......