Which of the following stable sorting algorithm takes the least time when applied to an almost sorted array?
a) Quick sort
b) Insertion sort
c) Selection sort
d) Merge sort
why the answer is merge sort not insertion sort?
Related
What would be the time complexity If I will apply merge sort on an already sorted array?
Usual merge sort still uses O(nlogn) for sorted data.
But there is natural merge sort variant that provides linear complexity for sorted arrays.
Note that natural merge sort also gives O(nlogn) for arbitrary data, compared with isertion sort, that behaves well for sorted data but becomes quadratic in the worst case
According to the Wikipedia page for merge sort, merge sort has both a best and worse case performance of O(n log n). Given an input of an array already sorted, merge sort would still need to go through the same sorting process as for any other array. As a result, even for a sorted array, the running time would still be O(n log n).
For the case of an already-sorted array, there are other algorithms which actually beat merge sort, e.g. insertion sort. For insertion sort, the performance of an already sorted array is O(n), i.e. linear.
Question;
You have to sort an array of bank transactions by date. Most of them
are in order (by date), only a few are out of order.
Which sorting algorithm will you use between insertion sort, selection
sort and merge sort in order to take advantage of the fact that the
array is almost sorted?
My answer (not sure if its correct)
Assuming that N >= 5, i would go with Merge Sort since its avg. time complexity would be O(n * log n) which would be more efficient than insertion sort O(n^2). However, since multiple transactions will be on the same dates, insertion sort would be a good STABLE sorting method.
Which one is better in this case? Merge or insertion sort? Am i in the right direction?
You should pick insertion sort, not because of stability, but because it's adaptive (see here) and will outperform due to the fact the input is almost sorted to begin with.
The meaning of this "adaptive" characteristic is that elements that are already in place are processed at O(1) time, and elements very close to their sorted position can also be considered O(1) (up to some k distance).
If I have to sort one list and merge it with another already sorted one. Then what will the running time be if I use merge sort and insertion sort?
Merge sort is: n logn
Insertion sort is: n^2
But together they are?
EDIT: Oh, so what I actually meant was that I had to sort one of the lists and merge them together.
I have made the pseudocode for the insertion sort, but I don't know what the running time of the two algorithms will be.
http://gyazo.com/0010f053f0fe64a82dad1dd383740a3f
The complexity of merging two sorted lists with lengths n1 and n2 is O(n1 + n2); that should be enough to work out the big-Oh of the entire algorithm
I hava an array with the first until the N element are sorted and N+1 until elemnt N+M unsorted (the array consist of N+M elements). what is the complexity of sorting this array using insertion sort? I think it's (N+M)^2, is it so?
If you want to use insertion sort, you will need O(M*(M+N)) operation. However, a better approach could be sorting the unsorted part in O(M*lgM) and then merge two sorted parts in O(N+M).
Hey so I am trying to verify some of the sorting algorithms.
Insertion Sort
Mergesort
Quicksort using “median of three” partitioning and cutoff of 10 (using Insertion Sort for the small array portions)
Analysis:
The worst case running time for Insertion Sort was discussed to be O(n2), with actual running time O(n) for sorted input (as long as the inside loop is properly coded). Mergesort was discussed to be O(n log n) for all input. Quicksort using the “median of three” partitioning and a reasonable cutoff was discussed to be O(n Log(n)) for all input, but faster in practice than Mergesort. Do your timings validate these computations?
note that N = Max/2 , and 2N = MAX
After running the programs, i found that
The diff for insertion sorted with sorted max/2 is 0.000307083129882812
The diff for insertion sorted with sorted max is 0.000623941421508789
The diff for insertion reverse with sorted max/2 is 0.000306129455566406
The diff for insertion reverse with sorted max is 0.000745058059692383
The diff for insertion random with sorted max/2 is 2.39158606529236
The diff for insertion random with sorted max is 9.72073698043823
The diff for merge sort with sorted max/2 is 0.00736188888549805
The diff for merge sort with sorted max is 0.0154471397399902
The diff for merge reverse with sorted max/2 is 0.00730609893798828
The diff for merge reverse with sorted max is 0.0154309272766113
The diff for merge random with sorted max/2 is 0.0109999179840088
The diff for merge random with sorted max is 0.0232758522033691
The diff for quick sorted with sorted max/2 is 3.10367894172668
The diff for quick sorted with sorted max is 12.5512340068817
The diff for quick reverse with sorted max/2 is 3.09689497947693
The diff for quick reverse with sorted max is 12.5547797679901
The diff for quick random with sorted max/2 is 0.0112619400024414
The diff for quick random with sorted max is 0.0221798419952393
I know that the insertion sort is working correctly since for the random, i did 9.72073698043823/ 2.39158606529236 ~= 4 = 22 = O(n2)
but I don't know how to verify if the others ones are O(n Log(n)) or not. Please help
Let me remind you that f(n)=O(n) means limit when n grows very big that f(n)/n => constant
What is not said :
that constant can be very big
that for small values, it means something : e.g. 10^9/n+n is O(n) but for n=1, it0s 10^9+1 ;-)
O(something) is not the argument killer, topology of your data may sometime affect the algorithm (e.g: on "almost" sorted data, bubble sort performs well)
If you want to draw conclusions, run test with big samples relevant for your application, don't draw conclusion too early (note that modern CPU might fool you with cache, pipelining and multicore if you use it (what you can for sorting)