Why is quick sorting faster?

This is a question I have been thinking about. Why is it fast sorting? I forgot my thoughts and was asked yesterday. Naturally, I couldn't come up with a good answer. Until I see the answer to this question in "dark time.

 

In "dark time", Liu weiran did not directly give the answer. Instead, he first talked about two games: Guessing numbers and playing balls. Both questions are easy to understand and can be easily answered. However, what makes me suddenly clear is that they point to the same idea and conquer it separately! Cut questions by half and half until the answer goes down.

 

Back to the question, our goal is to sort. No matter which sort method is based on the comparison between two, the question is, how can we reduce the number of comparisons? For example, there are 11 numbers in a group: 1, 2, 3, 4, 5, 15, 78, 89, and 90,100,200. In addition, the initial order is from small to large, and now it is arranged from large to small. The idea of quick sorting is to extract a number (referred to as a benchmark) from the base, and then be smaller than or equal to the one on the other. For example, if 78 is randomly selected, 100,200, will be on one side, and will be on the other side. At this time, it is noted that from this moment on, those numbers smaller than 78 will no longer have a chance to compare them with those larger than 78. Fast sorting uses the divide-and-conquer idea. Although, because of random extraction, we 'd better get 15 for the first time, so we can divide it equally. But it does not matter. By ignoring this random factor, kubernetes still divides the big problem into two small problems, even if these two word problems are not necessarily equal. As long as the recursion goes on, the result goes smoothly.

 

On the contrary, let's take a look at the heap sorting of the same time complexity (O (nlogn) in theory and the same as the fast rank. Let's just say the largest heap. After it removes the largest element, the final leaf node is taken up to rebuild the heap. However, obviously, the value is much smaller than the two leaf nodes. It takes many times to return to the proper position. Besides, I found that before the value of the parent node is compared with that of the Child Tree node, the left and right subtree must be compared first, then compare the size with the parent node with the largest one.

Two-to-two comparisons made a meaningful exchange. As a result, heap sorting is useless!

 

The above logic analyzes the reason why quick sorting is faster than Merge Sorting and heap sorting. However, this is not enough. Then, analyze their time complexity from mathematical statistics --

(1) Heap sorting --

In the heap building process, because we are building a Complete Binary Tree from the rightmost non-terminal node in the bottom layer, We will compare it with our children and swap it if necessary, for each non-terminal node, the comparison and interchange operations can be performed at most two times. Therefore, the time complexity of the entire build heap is O (n ).

In the formal sorting, the I-th time to retrieve the top record of the heap and rebuild the heap requires O (Logi) time (the distance from a node of the Complete Binary Tree to the root node is. log2i. + 1), n-1-1 heap top record is required. Therefore, the time complexity of rebuilding the heap is O (nlogn ).

(2) Merge and sort --

If T (n) is used to sort the arrays composed of n elements by means of Merge Sorting, mergetime is used to represent the time it takes to merge the two subgroups. So

T (n) = T (n/2) + T (n/2) + mergetime

Megetime is the time used to merge two sub-arrays. The maximum time is used. A maximum of n-1 times are required to compare the elements of the two sub-arrays, and then n times are moved to the temporary array. Then mergetime is 2n-1.

Therefore, T (n) = T (n/2) + T (n/2) + 2n-1.

 

(3) Fast sorting --

In the worst caseTo divide the arrays of n elements, it takes n comparisons and N moves. Suppose T (n) is used to represent the time it takes to sort arrays of n elements using a fast sorting algorithm. So

T (n) = T (n/2) + T (n/2) + 2N

 

In this case, some people may think that, in terms of mathematical formulas, the Merge Sorting is less than the fast sorting by 1, isn't it faster? In fact, this is not the case. Please note the words "worst case", that is, the benchmark that I select each time depends on the input benchmark, which is the least ideal benchmark, you can only achieve the goal by moving it up to a maximum of times. However, the probability of such a situation is 1/(2 ^ N), which is very small. Moreover, this is the most common fast sorting method, and many optimization solutions have been proposed, one of the most common features is to use random functions to select benchmarks to avoid the worst case.

 

In the competition of algorithm art and Informatics, the best-selling ACM information competition textbook, the author also raised the issue of efficiency and optimization of fast sorting --

 

As we have analyzed, once we use a random function to generate a benchmark, in the time complexity calculation formula,

T (n) = T (n/2) + T (n/2) + 2n is no longer 2n, maybe 1, maybe 2... however, the final result must be much smaller than 2n.

 

As for the heap sorting, it is obvious that the heap sorting mainly takes a long time to adjust the heap, and 90% of the time is consumed on the heap adjustment. Therefore, when the data volume is large, it is obviously far behind.

 

So far, I want to understand why kubernetes is faster than the other two because it is good at breaking down sub-problems and never does nothing. Although there are worst cases, this can minimize the probability of occurrence. If you have different opinions, please click it. Thank you.