views:

1131

answers:

5

The last week I stumbled over this paper where the authors mention on the second page:

Note that this yields a linear running time for integer edge weights.

The same on the third page:

This yields a linear running time for integer edge weights and O(m log n) for comparison-based sorting.

And on the 8th page:

In particular, using fast integer sorting would probably accelerate GPA considerably.

Does this mean that there is a O(n) sorting algorithm under special circumstances for integer values? Or is this a specialty of graph theory?

PS:
It could be that reference [3] could be helpful because on the first page they say:

Further improvements have been achieved for [..] graph classes such as integer edge weights [3], [...]

but I didn't have access to any of the scientific journals.

+20  A: 

Yes, radix sort and counting sort are O(N). They are NOT comparison-based sorts, which have been proven to have Ω(N log N) lower bound.

To be precise, radix sort is O(kN), where k is the number of digits in the values to be sorted. Counting sort is O(N + k), where k is the range of the numbers to be sorted.

There are specific applications where k is small enough that both radix sort and counting sort exhibit linear-time performance in practice.

polygenelubricants
Lower bounds are always expressed as Ω. Saying an O lower bound has no semantic meaning. Otherwise +1.
Billy ONeal
Thanks for the correction =)
polygenelubricants
They're only `O(n)` if the biggest possible value of the integers is less than or equal to n - otherwise they're `O(max_int)`, no?
sepp2k
@sepp2k I added the `k` in there for clarification.
polygenelubricants
`O(kN)` where k is the number of digits is a bit misleading. k doesn't have to be the number of digits, it can be the number of **bytes**. For 32 bit integers, using k = 4 or even k = 2 will make radix sort very fast; much faster than using k = 10 and sorting by each digit. This makes the memory used **O(2^number_of_bits_in_a_byte)**.
IVlad
That's just semantics. Digits doesn't have to be base 10. I can set it to be base 256, and that's essentially the same as your argument.
polygenelubricants
Yes, semantics, which is why I said a bit misleading and not wrong :).
IVlad
To be precise, the number of digits is going to be proportional to the size of the numbers, and assuming you aren't just sorting endless duplicates the size of the numbers is proportional to the log of the number of numbers, so radix sort is O(n log n). It's just that the log n is not a factor as it's normally used.
David Thornley
@David "Radix sort's efficiency is thus O(kn) for n keys of k digits. Since k is normally on the order of log n, it might appear that radix sort does not really beat the O(n log n) time of the best comparison sorts. *However, the O(n log n) time of the best comparison sorts* **counts the number of comparisons**, and the fastest time possible for a comparison is k. If we count the number of primitive operations, then merge sort (or other fast comparison sorts) execute in O(kn log n) time."
polygenelubricants
@polygenelubricants comparison of integers does not take k time if hardware is wide enough.
Pete Kirkham
I'm not sure how often people sort `BigInteger` in practice, but nonetheless that remark (which I took verbatim from current version of Wikipedia article) is the standard counterargument to claims that radix sort is not linear.
polygenelubricants
+7  A: 
ephemient
Thanks @BillyONeal, I really should know better.
ephemient
+2  A: 

Counting sort: http://en.wikipedia.org/wiki/Counting_sort if your integers are fairly small. Radix sort if you have bigger numbers (this is basically a generalization of counting sort, or an optimization for bigger numbers if you will): http://en.wikipedia.org/wiki/Radix_sort

There is also bucket sort: http://en.wikipedia.org/wiki/Bucket_sort

IVlad
thanks a lot for the provided links!
Karussell
+1  A: 

Take a look at this from stack overflow, somebody had already asked a similar kind of question : Quantum sort

Bragboy
+1  A: 

While not very practical (mainly due to the large memory overhead), I thought I would mention Abacus (Bead) Sort as another interesting linear time sorting algorithm.

Dolphin
thanks this is a nice one!
Karussell