i need a simple implementation of sorting algorithm in linear time and efficient ? like radix sort or counting sort ? are they really better than merge sort ..if so why people always use nlogn algorithms ?
# | User | Rating |
---|---|---|
1 | tourist | 3993 |
2 | jiangly | 3743 |
3 | orzdevinwang | 3707 |
4 | Radewoosh | 3627 |
5 | jqdai0815 | 3620 |
6 | Benq | 3564 |
7 | Kevin114514 | 3443 |
8 | ksun48 | 3434 |
9 | Rewinding | 3397 |
10 | Um_nik | 3396 |
# | User | Contrib. |
---|---|---|
1 | cry | 167 |
2 | Um_nik | 163 |
3 | maomao90 | 162 |
3 | atcoder_official | 162 |
5 | adamant | 159 |
6 | -is-this-fft- | 158 |
7 | awoo | 157 |
8 | TheScrasse | 154 |
9 | Dominater069 | 153 |
9 | nor | 153 |
i need a simple implementation of sorting algorithm in linear time and efficient ? like radix sort or counting sort ? are they really better than merge sort ..if so why people always use nlogn algorithms ?
Name |
---|
There can't exist a sorting the runs in a linear time, because you need to make comparisons whether directly like merge sort, quick sort, bubble sort, ... etc or indirectly like radix sort.
how can you sort items when you don't compare them to their surroundings? and if you compare how can the complexity of such algorithm be linear?!
i mean classification sorting algorithms like radix sort or counting sort they run in linear time !
Radix Sort is linear only because it is non-comparative, and Counting Sort takes expected linear time if you use a hashtable (it's not guaranteed linear, it's just linear with high probability).
In general, you cannot do better than if you're using a comparative sorting algorithm. If you have a well-defined ordering on some objects, then you can sort them in assuming you can compare them in O(1).
If you take advantage of some underlying structure within those objects, then yes, you could sort faster than . That's where Radix Sort comes from. It solves the problem of sorting integers specifically, not the problem of sorting objects with an ordering.
It's less effort to just use
std::sort
and be okay with a factor. It's not wrong to use Radix Sort for integers, it's just that in a contest, there's a tradeoff between how well it would benefit your solution, and the time you need to implement it (also, the maintenance cost, and the probability that your implementation has a bug play a role).Radix sort isn't really linear though, but rather where M is the largest number, which isn't that much better/different in theory from since we often have M > N.
(In practice we can make radix sort quite efficient though by processing x-bit chunks at the time.)