2

The while loop uses linear search to scan backwards. However, we know that the array within the while loop is already sorted. So we can replace the linear search with binary search instead so that O(n) will change to O(lg n). However, my take on this is that it won't contribute to reducing the overall time because we would still have to move the elements one index forward which will always take (number of backward steps(n)) times. So overall, the running time stays O(n^2) and there is no way to achieve O(n lg n) for this case. Please tell me if I am approaching this in a wrong way.

INSERTION-SORT(A)

 for j = 2 to length[A]
  do key = A[j]
     i = j - 1

  while i > 0 and A[i] > key
    A[i+1] = A[i]
    i = i - 1

  A[i+1] = key
Rafay
  • 6,108
  • 11
  • 51
  • 71
  • FYI: http://en.wikipedia.org/wiki/Timsort is a hybrid sorting algorithm, derived from merge sort and insertion sort, designed to perform well on many kinds of real-world data. – nodakai Feb 27 '12 at 15:45
  • I'm not clear on what your real goal is, so I can't say if you're approaching it the right way or not. However, if I understand you correctly, what you said is correct - replacing the O(n) search with an O(log n) search makes no asymptotic difference if you follow that search with an O(n) mutation of the array anyway. In fact, using a binary search is only likely to make even a constant-factors improvement if the comparisons are particularly expensive. E.g. there's no locality/memory bandwidth improvement - you'll need to read/write that whole range anyway, and a single pass is optimal. –  Feb 27 '12 at 15:50
  • The normal favorite comparison-based sorts are quicksort, mergesort and heapsort. Quicksort is worst-case O(n^2), but with minor tweaks, O(n log n) in practice, and very good for locality etc. Mergesort and heapsort are worst-case O(n log n) but not so good for locality, though mergesort can have very good locality if you're OK with using extra memory (don't sort in-place - each pass copies the data). Actually, possible confusion there - I'm not sure mergesort is do-able in-place at all. –  Feb 27 '12 at 15:56
  • 1
    This is an exercise in CLRS chapter 2, for those who are wondering why would anyone want to even consider this. – yati sagade Apr 14 '13 at 11:28

4 Answers4

6

insertion sort pushes the elements of the array in order to free a space to the next element in line.
so if you find where to enter the new element using binary search, you will still need to push all the elements after that index one step forward (to the right).
so given an array sorted backwards: 10,9,8,7,6,5,4,3,2,1
you will need to make i-1 pushes to the right in order to insert the i'th element (even if you use binary search) - worst case time: O(n^2)
if you could insert the elements, one by one, to a list you wouldn't have to push the elements, but you will have to "pay" for the search of the proper location in the list (so in this implementation W.C.T is O(n^2)).

a solution to this problem will be with some kind of synergy between lists and arrays so you could reach the i'th element in O(1) time (as in arrays) and could push a new element to a given location (say after the index j) in O(1) time (as in lists) - if you succeed, I believe you will win eternal glory!

Shai Balassiano
  • 997
  • 2
  • 10
  • 21
1

Binary searching for the insertion point can provide a slight improvement, mainly by removing the key comparison from the loop that shifts elements up. The difference won't be significant until you are sorting a large amount of data. Of course, if you have a large dataset you should be using a better sorting algorithm...

Blastfurnace
  • 18,411
  • 56
  • 55
  • 70
0

Basically, the time needed for an insertion sort is composed of three factors.

  1. Going over every element in the SOURCE array
  2. Finding the right location to insert it into the DESTINATION array
  3. Doing the insert.

What you are talking about concerns step 2. A naive way would be to go through the full DESTINATION array to find the insert location, which takes O(n). However, you can do a binary search which would only take you O(log(n)).

You still need to do the insert, but the cost of that is dependent on the data structure. If you use a linked list, it will always take you a constant amount of time. If you use a simple Array, you can just do a memcpy() which should scale equally well. The approach you use in pseudo-code is a very naive approach and would never be valid in a real implementation. See http://www.docjar.com/html/api/java/util/ArrayList.java.html#421 for a real-life example of an INSERT for Arrays. System.arraycopy() is O(1).

parasietje
  • 1,529
  • 8
  • 36
-1

I think the running time is O(nlgn).. binary search takes lgn time.. and moving the elements takes O(n/2) in the worst case, which is "asymptotically the same" as O(n) [I can't find the 'belongs to' symbol.. :D]

And I don't think the pseudo-code that you gave is insertion sort with binary search.

Neo
  • 1,554
  • 2
  • 15
  • 28