Java, sorting analysis. Heapsort, Quicksort1, Quicksort2, Mergesort, given a blackbox

Question

I was given a class in Java called BlackBox.java. There are four types of sorting methods in this class and they are called sort1, sort2, sort3 and sort4. It is given that we have Mergesort, Heapsort, Quicksort with the first place in the array as pivot (does not use StdRandom.shuffle), and finally we have Quicksort which take the middle of first and last elements and use that as pivot (also does not use StdRandom.shuffle).

The problem is that I need to find out which sorting method (sort1, sort2, sort3, sort4) is what. I have already counted the time with input of 500.000 integers. First I used random ordered input, than I used input sorted regularly and than I used input sorted reverse and finally I used a really big input with the same integer, 3 everywhere ({3 3 3 3 3...}). Sometimes I got stack overflow and sometimes not. I also got very similar sorting time for all of them, I mean very similar that I was not able to use it to tell which sorting algorithm I was using.

How can I find out which algorithm is what? What methods should I use?

P.s. I have already read chapter 1.4 in the book Algorithms written by Sedgewick and wayne and done alot of search on the internet. Maybe I am not understanding chapter 1.4 enough. So, I ask you to help me with this problem if you can.

Also, I am not aloud to check the bytecode.

Answer 1

there are 3 main differences between all these algorithms:

1. order preserving (stable/unstalbe)
2. order in which different objects are compared to each other (or pivot)
3. order in which different objects are swapped

to test for order preserving you need to sort objects with one property to sort on and second one to distinguish them, for example:

class item {
  int sortid;
  string name;

  compareTo(item) -> return compare(this.sortid, item.sortid); note that name is not used
}

so, by supplying array, which have non-unique sortid, but different names you can check algorithms for stability, note - you need to use multiple inputs to see stability, as even non-stable ones could return stable order:

• merge - stable
• heap - not stable
• quick - not stable

different implementation of quick sorts will first try to move objects smaller to pivot to the left and greater to right, so if you find that your elements are compared with first element - it is first implementation of pivot, if with middle - it is second implementation of quick sort

to implement this, you need to pass objects with custom comparison, which will check which element they are compare to and they know what can be used as pivot, so first comparison will give you answer which pivot is actually used by which sort method

at this point it will be clear which one is heap, but if you have ability to monitor element swaps, you can also detect heap, as it starts putting smallest/largest elements first

Answer 2

If you're able to measure the running times, then one approach is construct best- and worst-case inputs for each algorithm and see which ones slow down in which cases, and by how much.

• The easiest case is quicksort choosing the first element as the pivot; this degrades to quadratic time when the array is already in order, or in reverse order. The best case can be constructed by making sure the pivot is always the median of the elements in that subarray.
• The next-easiest case is quicksort using the middle of the array as the pivot; this likewise degrades to quadratic time for some inputs, but it is a little bit harder to construct such inputs. The best case is when the array is already in order or in reverse order, so that the middle element is always the median.
• Merge sort is still O(n log n) in the worst case, but nonetheless it is slower on some kinds of inputs. The "merge" stage does fewest comparisons when all the elements in one array are less than all the elements in the other array, and the most comparisons when the two arrays are "interleaved" as much as possible.
• Heapsort is still O(n log n) in the worst case, but likewise can be faster or slower depending on how far each element has to be "sifted down".

This will possibly be harder than spying on the algorithms' internal workings using a custom comparator that logs which elements are compared in what order, but I think it is more likely to be the solution intended by your professor.