Saturday, March 29, 2014

Week 11

This is the last topic of CSC148 --- sort and efficiency.  The sorting methods we are looking at put a list of items in an ascending order.  We've done different kinds of sorting methods in CSC108, including bubble sort, selection sort and insertion sort.  But in CSC148, we are digging more into the sorting algorithms and learning to analyze their efficiency on different sizes of lists, with the addition of some new sorting algorithms (including quick sort, merge sort, count sort, built-in/tim sort).  In order to do the running-time analysis, the 'big-oh', O(g), is being introduced.  The 'big-oh' describes the algorithm's behaviour over a large input of size n.  I haven't heard of the 'big-oh' before so the idea was a little bit vague to me.  But after Professor Heap explained it, it becomes much clearer to me.


There are two very important, new sorting algorithms introduced.  One is quick sort, the other is merge sort.

1) Quick sort picks a pivot and puts values greater than the pivot value to the right of the pivot and values less than the pivot value to the left of the pivot.  After doing that, the pivot value is at the right position.  It continues to pick pivots on sublists and quick sort the sublists.


2) Merge sort splits the list into halves recursively, sort each half and merge them together.  


In the average case, both sorting algorithms are O(nlogn).  This is more efficient than the sorting methods we learnt before.  To fully understand and get familiar with these sorting algorithms, I practiced writing their codes on my own.  And then I get to understand their 'big-oh's as well.  For quick sort, it chooses the pivot logn times and for merge sort, it divides the list into halves logn times.  And each partition has O(n) complexity.  Therefore, the overall complexity is O(nlogn).


However, it is not always the case.  For example, in the worst case of quick sort, the complexity is O(n^2).  So we need to analyze best, average and worst cases of sorting algorithms respectively.  In the last lab, we tested three situations for each sort: 1) random list  2) sorted list  3) sorted and reversed list.  After we transform the data into graph, the graph gave us a very clear image on how different sorting algorithms perform.  Moreover, the performance also depends on how the codes are written.  I discussed a lot with my partner to figure out why different codes result in better/worse efficiency. 


In addition, we looked at count sort which sorts consecutive integers.  And there is the very efficient built-in sort (i.e. tim-sort).  By testing it in the lab, we found it much faster than any other sorting algorithms.  But it seems like it is also more complex comparing to the other ones.  Even though I studied the above sorting algorithms, it was still quite challenging for me to analyze the ones in the test.  I still have to practice more about the 'big-oh'.


No comments:

Post a Comment