Sorting $m$ Integers in $O(m)$ Time

Click For Summary

Discussion Overview

The discussion revolves around the possibility of sorting $m$ integers with values between $0$ and $m^2-1$ in $O(m)$ time. Participants explore various sorting algorithms, particularly radix sort, and debate the complexities involved in achieving linear time sorting under the specified conditions.

Discussion Character

  • Debate/contested
  • Technical explanation
  • Mathematical reasoning

Main Points Raised

  • Some participants question whether it is possible to sort $m$ integers in $O(m)$ time, citing that comparison-based sort algorithms have a worst-case complexity of $\Omega(m \log m)$.
  • Radix sort is mentioned as a potential candidate for achieving linear time complexity, but concerns are raised about its worst-case order being $O(dm)$, which translates to $O(m \log m)$ in this context.
  • There is a suggestion to consider changing the base of the logarithm in the complexity analysis, but this is challenged as it may revert to conventional sorting methods that rely on comparisons.
  • Participants discuss the implications of knowing the range of numbers, noting that if the integers were limited (e.g., between 0 and 9999), sorting could be achieved in $O(m)$ time.
  • A code snippet for a counting sort algorithm is shared, but the poster expresses uncertainty about how it operates and seeks clarification.
  • Another participant summarizes the counting sort process, describing it as creating a histogram of values and transferring them to the output, which is acknowledged as an $O(n)$ operation.

Areas of Agreement / Disagreement

Participants do not reach a consensus on whether sorting $m$ integers in $O(m)$ time is feasible. Multiple competing views regarding the effectiveness of radix sort and counting sort are presented, and the discussion remains unresolved.

Contextual Notes

Participants highlight the dependence on the range of integers and the assumptions regarding the sorting algorithms' complexities. The discussion reflects uncertainty about the applicability of different sorting methods under the given constraints.

evinda
Gold Member
MHB
Messages
3,741
Reaction score
0
Hello! (Smile)

How could we show that we can sort $m$ integers with values between $0$ and $m^2-1$ in $O(m)$ time? (Thinking)
 
Technology news on Phys.org
Do I have to write an algorithm or write the steps that have to be done? (Thinking)
 
evinda said:
Hello! (Smile)

How could we show that we can sort $m$ integers with values between $0$ and $m^2-1$ in $O(m)$ time? (Thinking)

Hey! (Wave)

I'm not so sure it is possible - at least not for a worst case scenario.
Sort routines that are based on only comparisons of the values are guaranteed to be of order $\Omega(m\log m)$ for a worst case scenario. (Sweating)

See wiki for a list of sort algorithms and their complexities.

A typical candidate would be radix sort, which does not rely on basic comparisons, but even radix sort does not seem to be good enough, since its worst case order is $O(dm)$ where $d$ is the number of digits. In this case that still comes out as $O(\log(m^2)m) = O(m \log m)$. (Nerd)
 
I like Serena said:
Hey! (Wave)

I'm not so sure it is possible - at least not for a worst case scenario.
Sort routines that are based on only comparisons of the values are guaranteed to be of order $\Omega(m\log m)$ for a worst case scenario. (Sweating)

See wiki for a list of sort algorithms and their complexities.

A typical candidate would be radix sort, which does not rely on basic comparisons, but even radix sort does not seem to be good enough, since its worst case order is $O(dm)$ where $d$ is the number of digits. In this case that still comes out as $O(\log(m^2)m) = O(m \log m)$. (Nerd)

Do we have to change maybe the base of the logarithm to $m$, so that $O(m \log m)=O(m)$ ? (Thinking)
 
evinda said:
Do we have to change maybe the base of the logarithm to $m$, so that $O(m \log m)=O(m)$ ? (Thinking)

Radix sort is supposed to work with a fixed base for the digits, so it can't scale with $m$. (Nerd)

And anyway, if we would have digits in base-$m$, we are effectively back at a conventional sorting algorithm that only uses normal comparisons. (Doh)
 
I like Serena said:
Radix sort is supposed to work with a fixed base for the digits, so it can't scale with $m$. (Nerd)

And anyway, if we would have digits in base-$m$, we are effectively back at a conventional sorting algorithm that only uses normal comparisons. (Doh)

So couldn't we use the fact that $\log_2 n=\frac{\log_m n}{\log_m 2}$ ? (Thinking)
 
When we apply the radix sort in this case, what will be the complexity? (Thinking)
 
evinda said:
When we apply the radix sort in this case, what will be the complexity? (Thinking)

I like Serena said:
even radix sort does not seem to be good enough, since its worst case order is $O(dm)$ where $d$ is the number of digits. In this case that still comes out as $O(\log(m^2)m) = O(m \log m)$. (Nerd)

There you go. (Wasntme)

Now if we knew for instance that the numbers were between 0 and 9999, the complexity would be $O(m)$. Alas that is not the case.
 
I like Serena said:
There you go. (Wasntme)

Now if we knew for instance that the numbers were between 0 and 9999, the complexity would be $O(m)$. Alas that is not the case.

When we consider the base $b$ and we want to find the greatest number with $d$ digits, this number will be equal to $b^d-1$.

So, in our case isn't it $d=2$? (Thinking)

- - - Updated - - -

If so, then we will have to use this algorithm:

Code:
int countSort(int arr[], int n, int exp)
{
    int output[n]; 
    int i, count[n] ;
    for (int i=0; i < n; i++)
       count[i] = 0;
    for (i = 0; i < n; i++)
        count[ (arr[i]/exp)%n ]++;
    for (i = 1; i < n; i++)
        count[i] += count[i - 1];
    for (i = n - 1; i >= 0; i--)
    {
        output[count[ (arr[i]/exp)%n] - 1] = arr[i];
        count[(arr[i]/exp)%n]--;
    }
    for (i = 0; i < n; i++)
        arr[i] = output[i];
}

Code:
void sort(int arr[], int n)
{
    countSort(arr, n, 1);
    countSort(arr, n, n);
}
But I haven't understood how it works... Could you explain it to me? (Thinking)
 
  • #10
That makes sense. (Smile)

As I understand the counting sort algorithm, we make a histogram of all values, which is O(n). And then we iterate through it, transferring all histogram values to the output.
Presto! (Mmm)
 

Similar threads

  • · Replies 1 ·
Replies
1
Views
2K
  • · Replies 20 ·
Replies
20
Views
4K
Replies
5
Views
2K
  • · Replies 17 ·
Replies
17
Views
4K
  • · Replies 3 ·
Replies
3
Views
2K
Replies
1
Views
2K
  • · Replies 4 ·
Replies
4
Views
4K
  • · Replies 5 ·
Replies
5
Views
4K
  • · Replies 2 ·
Replies
2
Views
2K
Replies
7
Views
2K