Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Why is merge sort worst case run time O (n log n)?

Can someone explain to me in simple English or an easy way to explain it?

like image 627
adit Avatar asked Oct 18 '11 02:10

adit


People also ask

Why is merge sort worst case?

In short, the worst case of Merge Sort is when the left and right array has alternating elements. This results in maximum number of comparison and the Time Complexity stays at O(N logN).

What is the runtime of merge sort and why?

Merge Sort is a stable sort which means that the same element in an array maintain their original positions with respect to each other. Overall time complexity of Merge sort is O(nLogn). It is more efficient as it is in worst case also the runtime is O(nlogn) The space complexity of Merge sort is O(n).

Why is the complexity of merge sort O nLogn?

Merge Sort separates the array in half and takes linear time to merge the two halves. Hence its time complexity is nLogn in all three scenarios (worst, average, and best). It divides the input array in half, makes two separate calls for each half, and then joins the two sorted halves.

What is the running time of the merge operation in merge sort?

Merge Sort is quite fast, and has a time complexity of O(n*log n) . It is also a stable sort, which means the "equal" elements are ordered in the same order in the sorted list. In this section we will understand why the running time for merge sort is O(n*log n) .


2 Answers

The Merge Sort use the Divide-and-Conquer approach to solve the sorting problem. First, it divides the input in half using recursion. After dividing, it sort the halfs and merge them into one sorted output. See the figure

MergeSort recursion tree

It means that is better to sort half of your problem first and do a simple merge subroutine. So it is important to know the complexity of the merge subroutine and how many times it will be called in the recursion.

The pseudo-code for the merge sort is really simple.

# C = output [length = N] # A 1st sorted half [N/2] # B 2nd sorted half [N/2] i = j = 1 for k = 1 to n     if A[i] < B[j]         C[k] = A[i]         i++     else         C[k] = B[j]         j++ 

It is easy to see that in every loop you will have 4 operations: k++, i++ or j++, the if statement and the attribution C = A|B. So you will have less or equal to 4N + 2 operations giving a O(N) complexity. For the sake of the proof 4N + 2 will be treated as 6N, since is true for N = 1 (4N +2 <= 6N).

So assume you have an input with N elements and assume N is a power of 2. At every level you have two times more subproblems with an input with half elements from the previous input. This means that at the the level j = 0, 1, 2, ..., lgN there will be 2^j subproblems with an input of length N / 2^j. The number of operations at each level j will be less or equal to

2^j * 6(N / 2^j) = 6N

Observe that it doens't matter the level you will always have less or equal 6N operations.

Since there are lgN + 1 levels, the complexity will be

O(6N * (lgN + 1)) = O(6N*lgN + 6N) = O(n lgN)

References:

  • Coursera course Algorithms: Design and Analysis, Part 1
like image 167
Davi Sampaio Avatar answered Oct 14 '22 11:10

Davi Sampaio


On a "traditional" merge sort, each pass through the data doubles the size of the sorted subsections. After the first pass, the file will be sorted into sections of length two. After the second pass, length four. Then eight, sixteen, etc. up to the size of the file.

It's necessary to keep doubling the size of the sorted sections until there's one section comprising the whole file. It will take lg(N) doublings of the section size to reach the file size, and each pass of the data will take time proportional to the number of records.

like image 26
supercat Avatar answered Oct 14 '22 11:10

supercat