http://www.codeproject.com/KB/recipes/StableQuickSort.aspx?display=Print

The same application also has an in-place version of merge sort that uses O(logN) extra space and runs in a similar time.

Craig

I feel I should make a few points. The first is that this is by no means optimal. I just wanted to use it as a vehicle to discuss the Memory/CPU tradeoff. If I had put more time and read more than the Wikipedia article on the sort, I’m sure I could have come up with a more efficient version. This is not something that I would, for example, turn in to my professors.

About “variably-stable” that wasn’t describing any implementation of the sort, that was describing that the general specification of a quicksort meant that it could be implemented either way. It’s not inherently stable or unstable. (Perhaps this is true of all sorts, I’ve not studied many extensively. If you read the post about Python, you’ll see that I started learning this quicksort as a way to avoid learning a lot of sorts, for now.)

You guys are coders far and above my readers or myself, so I’m not surprised you guys picked me apart. I just hope that you boys had a good time.

And tj: the quicksort(), for better or worse, returns the sorted list. You’re not taking it’s return, so of course you’re getting abnormal output.

int[] arr2 = {2, 1};
quicksort(arr2);
System.out.printf(Arrays.toString(arr2)); // [2, 1]

If not, you will spend a lot of time simply copying information around.

Here’s another version, in less lines of code.

public void quicksort(int[] array, int first, int last) {
if (first >= last) return;

int pivot = array[(first + last) / 2];
int i1 = first, i2 = last;
while (i1 < i2) {
while (i1 < i2 && array[i1] <= pivot) i1++;
while (i1 pivot) i2–;
if (i1 < i2) {
Integer tmp = array[i1];
array[i1] = array[i2];
array[i2] = tmp;
}
}
quicksort(array, first, i1 – 1);
quicksort(array, i1, last);
}
public void quicksort(int[] array) {
quicksort(array, 0, array.length -1);
}

Notice that in practice, you will never use this. Use the available sort methods in classes java.util.Arrays and java.util.Collections.

Concerning using a Vector — if you set the initial capacity to size of the source list you’re basically allocating an array in memory that is that size. It won’t _need_ to resize, and all you gain is adjusting bounds.

I really think that if stability isn’t a problem, in-place quicksort is the way to go. It really hurts me, conceptually, to allocate full-sized arrays for each side. Naturally it helps that you adjust that size at each recursive step, but still.

As a side note, it’s also a better idea to use ArrayList instead of Vector in general, since Vectors are synchronized and therefore out of step with the rest of Java Collections. ArrayLists can be synchronized using Collections.synchronizedCollection().

1. The concept of a “variably stable” sort isn’t really legitimate. What you’re saying is that if your sort is unstable, you can make it stable by sorting on the values after you sort on keys. Well I could do that for any sort.

The fact is that this doesn’t make it stable. Stable doesn’t mean “when I’m done, it’s perfectly sorted”. It means that for sorting lists with duplicate keys, the elements which share keys remain in their original order (relative to each other). In other words, you don’t swap two elements unless you have to.

Quicksort is never stable. (The wiki article says “in efficient implementations” – this means that you can make quicksort stable, but then it won’t be quick!)

2. Why do we care about stable sorts? Well sometimes we do and sometimes we don’t. Usually when humans are looking at the data, they want it to be stable — simply because it *doesn’t make sense* if the computer reorders data for no reason.

Consider an Excel spreadsheet with a “Gender” column (M or F) and a “Name” column. Now I choose to sort by Gender. When I click sort, I want all the males at the top, then the females. But within those categories, I don’t want to see all the names jumbled up randomly. It would seem weird to me, as a human – why did the computer decide to scramble up all my names? I’d prefer it if it kept the original order except for splitting them into the 2 groups.

Even worse, if I click “sort” on already-sorted data, it would look stupid if it decided to jumble up the data even though it was already sorted.

This is why in some situations it is desirable to have a stable sort. So if I was implementing a spreadsheet, I’d do a merge sort (another algorithm that can be made stable, and is approximately as efficient as quicksort, with various different tradeoffs).

It’s a pretty good idea to consider what the performance is if the list is already sorted. This situation comes up quite a bit if you have programs that are always sorting the data. (Especially important is the “almost sorted” case, which might arise if you have a sorted list, and add 1 item to the end, and then re-sort it — in this case Insertion Sort is way more efficient than Quicksort).

Having said that, using a bubble sort to check if it’s already sorted is a Bad Idea. If you do a full bubble sort, obviously it’ll average out to be much slower than Quicksort. The suggestion to do 1 pass of bubble sort doesn’t make much sense either. It means you’re doing a whole extra pass over the data just for the special case of it being already sorted. You don’t need to make the already-sorted case super fast, just make sure it doesn’t kill your sort (which it won’t in the case of quicksort). Also there’s no point using bubble to pick the pivot.

But there *is* such thing as worst and best pivot – the best pivot is the one which separates the data 50/50. The worst pivot is the minimum or maximum value.

Consider in your code what happens if the list is already sorted – then your pivot selection (intlist[0]) will get the minimum value. Then your quicksort will recurse N times, and take N^2 comparisons to complete – JUST AS BAD AS BUBBLE SORT. So that’s a bad pivot selection.

How to improve pivot selection? If you take a whole pass over the data to pick an optimal pivot (the “bubble sort” suggestion), then you’ll waste as much time picking it as if you had picked the worst possible pivot!! So you can’t just write code to pick the best one.

Ideally, just pick an element from the list at random, or pick the middle element of the list (picking the middle element from the list gives you best performance on an already-sorted list).

As Fabse pointed out, it’s not really necessary to use arrays and manually keep track of their length, as Java has builtin list objects that do that for you. (They keep track of both the full length (called “capacity”) and the length of “good” items (called “size”)). However I would _not_ use a LinkedList. That won’t perform as you expect. I’d use a Vector, and be sure to set its initial capacity to the size of the source list.

Also why do you have 3 lists (less, greater, equal). Consider how many elements are put into the “equal” list. If you have 100 items, roughly distributed from 1 to 100, and a pivot of 50, then there’ll be about 50 items in the “less” list, 50 items in the “greater” list, and 1 item in the “equal” list. So don’t do that. Just have a “less than or equal to” list and a “greater than” list.

Really, the most CPU and memory efficient implementation would probably indeed use a linked list.

As to the bubble sort: it would be quicker and more efficient to just abort the search when you find an out of order item and begin with the quicksort. And as I understand Quicksort, there is no such thing as a “best” pivot. Everything gets sorted eventually.

I also think it would be reasonable to assume that a sorting algorithm would be used on unsorted data. If there was any question, it’s always possible for the program to test the data before passing it to the quicksort.