Sorting and Efficiency

    The past two weeks, most of the stuff we have learned in lectures is about Sorting and Efficiency. We learned various sorting algorithms, their code, efficiency, and when they are most and least productive.

   
    The bottom line is the built in sort is the fastest sorting algorithm for 99% of situations. The only situation that the built in sort was slower than a man-made algorithm was for quick sort at extremely high numbers, and where the value numbers being sorted were no greater than the length of the list in question. The main reason why the built in sort is the fastest algorithm is because it utilizes a series of algorithms and picks the best one accordingly. For example, many of the sorts that we went through in class took the same amount of time, or some times even more when a list was fully sorted.

    Algorithms like bubble sort and selection sort become essentially useless at quantities around 10^2 because they have to go through entire lists in every pass. Shell sort was a little bit faster because it broke up the list into incrementally smaller fragments, and then merge sort improved again on that because it compared stuff in two lists at an extremely fast pace. Finally quick sort was the king of man-made sorting algorithms, but only when the values of the lists were within the length of the list (in a list of length 100, the highest number is 100). If values exceeded the length of the list, there would be sufficient problems.