Tuesday, 1 April 2014

Sorting and Efficiency

I really hope I haven't missed a SLOG.

Sorting is an interesting topic in that there are so many ways to do it, but it's incredibly important to use the one most optimal for a given situation.  In high school I learned a massive amount of sorts (I can barely remember them all) but the one I remember using the most is the rather inefficient bubblesort.  Since then I've also learned quicksort, shellsort, selection sort, insertion sort, and radix sort.  I particularly enjoy radix sort, it's fast and quite easy to code, which is absolutely wonderful.

However, the most interesting part of sorting is still efficiency, and this comes from a basic understanding of how a sort works (and I was surprised how easily this stuff can be picked up).  Basically, just count the amount of times something happens, and follow these rules (my own thing):
a) if the list gets cut down, the time is O(n) or lower
b) if the list has one runtime only, the time is O(1)
c) if every count means counting everything else as well, the time is probably O(n^2)

The hardest part about the concept is to find the worst possible time - which I thought at first was the longest possible time, although that's simply not true.  Since the second term test, I have had to redefine my understanding to: the worst possible time is by comparison to the other possible times for any given test.  As a result it's not about considering the longest possible list to sort, but also which cases would break the rules.  For example, the midterm had a question where the list would be cut to 1/10 the size, and then a search would be performed from there.  The answer deals with thinking about when a list can't be cut into 10 pieces - which would be for any list that is size 9 or lower.  In those cases, the entire list has to be searched, meaning the worst possible time is O(n).  (FOR A TA MARKING THIS PLEASE CORRECT ME IF I'M WRONG HERE COMMENT BELOW THANKS)

I feel that finding efficiency is incredibly important in many algorithms and I always try to take it into account when finding algorithms.  Using an algorithm with too long a runtime is just unwieldy and useless (which is also why I changed my regex p2 algorithm quite substantially to minimize the runtimes).  In the future I will try to learn more about runtimes and how to reduce them.



1 comment:

  1. I have not seen the mid-term question. I would recommend going to office hours and/or talking to Danny!

    The TA.

    ReplyDelete