Hacker News Reader

Comment by testerofwaters | Hacker News Reader

It might just be faster because the author is comparing their hybrid radix sort implementation to std::sort (which is comparison-based).

Would be more valid to compare to Boost's "spreadsort" which is similarly a hybrid radix sort algorithm (and also outperforms std::sort).

View on HN

I had a feeling that O(N) is pretty impossible for the general use case.

I think there's a (provable) mathematical impossibility to have a general O(N) sorting algorithm

Basically, how many elements do you have to move in a list of N elements to end up with one of the possible orderings

You only ever have to move every element once to get a (pre-known) permutation that represents the sorted list.

The problem is the information in a permutation (n! possible orderings) and one can only ever "throw away" half of them on every comparison, leading to log_2(n!) or nlog(n).

It's not impossible to have a O(N) sorting algorithm if you add more constraints, e.g. use operations other than comparisons.

Most people would be fine with a hybrid radix sort for day to day use.

It is impossible for comparison-based sorts; sketch of proof: there are N! different arrangements. sorting is equivalent to figuring which one of those N! arrangements we are seeing. In the worst case, each binary comparison can reduce at most, 50% of the search space. Hence the worst case may need log_2(N!) comparisons, which is O(N log N)

However, it might be possible if comparisons are not essential - e.g. radix sort is (with some assumptions) O(N)

Why doesn't the STL switch to the hybrid sorting approach?

STL does use hybrid sorting. It is usually implemented as an introsort, which begins with a quicksort and switches to heapsort based on the number of elements to be sorted.

Sorry if that wasn't clear. I'm asking why don't they switch to the hybrid sort similar to Boost's, since it's known to be faster for most cases?

They probably should. After all Boost is often a staging area for C++ standard library.

AFAIK the STL is free to use any algorithm they want as long as it's O(n log n).

This is correct. The C++ standard specifies that sort must have a big-O complexity of n log(n). This can be seen on pdf page 925 of this working draft from 2014 [1].

[1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n429...

So providing a faster sort would be a violation?

The standard doesn't seem to say "or better" here, but I know that in other places it does (or least used to say something similar).

No, f = O(n log n) means that f doesn't grow significantly faster than n log n. That is true for f = n log n, but it's also true for f = n. The "or better" is implicit by using big-O.

Note that this wouldn't be true if the standard said that it has to be Θ(n log n).

Big O complexity is an upper bound.

If something is O(1) it's also O(n) and O(n!), since it's an upper bound.

"the" STL?

STL means "standard template library." It's perfectly reasonable to say "the standard template library."

There are several compatible and competing implementations of the C++ standard library.

I think the author just wanted to point out that "the" STL is not valid / accurate here; while the interface and behavior is defined, the implementation is afaik still vendor specific, e.g., the implementation in GCC may be different from the one provided by Microsoft.

The STL sort uses operator<, so they can't implement it as radix sort without changing the interface. Maybe they could manage to special case it for some fundamental types, but most likely they'd need to add a new function, like for stable_sort.

Reply on news.ycombinator.com