views:

141

answers:

3

Why quicksort(or introsort), or any comparison-based sorting algorithm is more common than radix-sort? Especially for sorting numbers.

Radix-sort is not comparison based, hence may be faster than O(n*logn). In fact, it is O(k*n), where k is the number of bits used to represent each item. And the memory overhead is not critical, since you may choose the number of buckets to use, and required memory may be less than mergesort's requirements.

Does it have to do with caching? Or maybe accessing random bytes of integers in the array?

+4  A: 

One obvious answer is that you can sort arbitrary types using quicksort (ie anything that's comparable), while you are restricted to numbers only with radix. And IMO quicksort is a lot more intuitive.

NullUserException
IMO Bubble Sort is more intuitive than Quicksort.
Justin Ardini
@Justin Indeed, but it's a heck slower.
NullUserException
True, but I'm more interested by the fact that the default sorting algorithms for numbers are implemented using quicksort. Especially the implementations in libraries, since the intuitivity is not of high importance, if the implementation of the sort() function is under the hood.
Daniyar
+3  A: 

Two arguments come to my mind:

  1. Quicksort/Introsort is more flexible:

    Quicksort and Introsort work well with all kinds of data. All you need for sorting is the possibility to compare items. This is trivial with numbers but you can sort other data as well.

    Radix sort on the other hand just sorts things by their binary representation. It never compares items against each other.

  2. Radix sort needs more memory.

    All radix sort implementations that I've seen use a secondary buffer to store partial sorting results. This increases the memory requirements of the sorting algorithm. That may not be a problem if you only sort a couple of kilobytes, but if you go into the gigabyte range it makes a huge difference.

    If I remember right a in place radix-sort algorithm exist on paper though.

Nils Pipenbrinck
The second argument is half-wrong. It is true that the radix sort needs more memory, but the memory required depends on the number of bits you use on each pass(number of buckets). Hence, the memory required may well be less than the requirements of mergesort, for example.
Daniyar
First argument is true, but I'm more interested by the fact that the default sorting algorithms for numbers are implemented using quicksort. Especially the implementations in libraries. And the fact that radix sort never compares items against each other is a good thing, since otherwise it's complexity would be limited O(n*logn).
Daniyar
A: 

Radix sort is slower for (most) real world use cases.

One reason is the complexity of the algorithm:

If items are unique, k >= log(n). Even with duplicate items, the set of problems where k < log(n) is small.

Another is the implementation:

The additional memory requirement (which in it self is a disadvantage), affects cache performance negatively.

I think it is safe to say that many libraries, like the standard library, use Quicksort because it performs better in the majority of cases. I don't think that "difficult implementation" or "less intuitive" are major factors.

Plow
Actually, if you read the last paragraph of the Efficiency section, you'll see that the given complexity is incorrect.
Daniyar
-1 for citing a source that is quite clearly of questionable quality.
stakx
@Daniyar You added a valid theoretical example in the first section you added to wikipedia. However, if you need efficient solutions for non-general datasets, you probably wont find it in most libraries. Bucket sort would be more efficient than radix sort in this example.The second example is even more theoretical and produces something that is only partially sorted.Quicksort is common because it is more efficient in (most) real world use cases.
Plow
@Plow I'm sorry, I'm confused. Which example? What section? I didn't add anything to wikipedia.
Daniyar
@stakx I found the article to be relevant. What makes you think otherwise?
Plow
@Daniyar Someone added two paragraphs to the efficiency section that I cited (as you can see in its revision history). Since you commented on that paragraph, I thought it was you that made the changes, but apparently not.
Plow
@Plow I didn't. The second last paragraph was there when you posted the link. Anyway, the discussion clearly shows that in terms of complexity, the radix sort is better than quicksort. Radix sort practically has linear running time. So, Radix sort is not slower.
Daniyar
_@Plow:_ There are two paragraphs in that Wikipedia article section. The first one says one thing, the second one says that the first paragraph is incorrect. Such contrary statements should not occur in an encyclopedia article -- on Wikipedia, the right place for such debates are the discussion pages, but not the main article page. The fact that you nevertheless see an argument going on on the main article page goes to show that it's not yet well consolidated and still needs more work towards making it a higher-quality article.
stakx
@stakx @Daniyar Just to be clear, when I linked to the article there were no argument going on, the two last paragraphs were added later (which can be seen in the revision history). The entire efficiency section has now been moved to discussions.
Plow
@Plow: Fair enough. Seeing that you've changed your answer, too, I've removed my downvote.
stakx