Jesse: Distributive partitioning sort seems like an interesting algorithm – I wasn’t aware of it. When splitting on median, it seems that the algorithm is O(N logN) in the worst case. Without that splitting, a killer set would be pretty easy to build, especially if the keys are floating point numbers.

E.g.: (1e100, 1e98, 1e96 … 1) would take O(N^2). On the other hand, this form of a ‘killer set’ cannot be generalized very far, since doubles only go up to 1e300 or so.

Basically a Bucket Sort where the number of buckets is equal to the number of elements to be sorted. The Bucket Selector function chooses the bucket based on the Key, Minimum, Maximum and number of elements.
Expected case: O(N); Worst case as defined: O(N * log N); Worst case with lazy code: O(N ^ 2)

As with Quick Sort, the lazy comparer/selector is the one prone to the worst case.
e.g., if the selector only looks at the first byte that is different across all keys, then it is easy to build a killer data set. Such a lazy selector would be O(N ^ 2), separating out one record per pass.

You could think of it as a Radix Sort where the largest possible key is a single digit in the chosen Radix.

Sadly, it generally requires high constants, so you really need a large data set to make it worth the trouble.

A typical median algorithm takes O(N) in the average case. But, as you say, the median algorithm will take O(N^2) for some bad cases.

However, there is a variant of the median algorithm that takes O(N) in the worst case. That’s the algorithm on the Wikipedia page that you linked to.

That algorithm has no “bad case” for the adversary to exploit.

Igor

I got this point when I read your article for the first time though. I understand the role of finding median in this scenario.

My only concern is that even finding median relies on the same ‘Compare’ function (the adversarial Compare) since the order between these elements is defined only by that function and uses the same partitioning technique as quicksort.

Now, don’t you think the median finding algo will also get screwed up badly and take O(N^2) instead of O(N)?

Once it takes O(N^2), quicksort will also takes O(N^2 log N).

Some quicksorts use median-of-3 algo. But, that will not serve the purpose here. Am I missing something here? Thanks again. If I am being a pain, please ignore this comment

Yes, my response was meant for you. And yes, I was referring to the linear selection algorithm that you linked to.

A typical quicksort implementation will pick the pivot in some “naive” way: pick the first element, or the middle element, or a pseudo-random element, etc. Such quicksort will get beaten by the adversary comparer.

However, you can actually pick the perfect pivot by computing the median of the array. Finding this pivot takes O(N) time. Using median find to select the pivot, the total running time of the quicksort is O(N logN) in the worst case – there are O(log N) recursion levels, and each level takes O(N) time.

I hope that is clear. By the way, the Wikipedia article you linked to also mentions the possibility of quicksort with worst case O(N log N): see the Important Notes section.

You might wonder why the median-based quick sort defeats the adversary. The reason is that the deterministic quicksort looks at O(N) elements before picking the pivot. And that is enough to guarantee that a good pivot will be chosen, even if the comparer acts as an adversary.

Was that a response towards me?

I fail to understand your claim of using a linear time median-finding algorithm to defeat the adversary. Could you please help me understand? Do you have this algorithm in mind for that approach?

http://en.wikipedia.org/wiki/S....._algorithm