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

In summary: 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.In summary, the counting sort algorithm transfers all histogram values to the output in order to minimize the number of comparisons made.
  • #1
evinda
Gold Member
MHB
3,836
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
  • #2
Do I have to write an algorithm or write the steps that have to be done? (Thinking)
 
  • #3
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)
 
  • #4
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)
 
  • #5
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)
 
  • #6
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)
 
  • #7
When we apply the radix sort in this case, what will be the complexity? (Thinking)
 
  • #8
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.
 
  • #9
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)
 

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

What does "Sorting $m$ Integers" mean?

Sorting $m$ Integers refers to arranging a set of $m$ numbers in ascending or descending order.

What is the significance of $O(m)$ time in sorting $m$ Integers?

$O(m)$ time complexity means that the algorithm used for sorting $m$ Integers has a linear time complexity, which is the most efficient time complexity for sorting. It means that the time taken to sort $m$ Integers increases linearly with the size of the input, making it a highly efficient and scalable algorithm.

What are the limitations of sorting $m$ Integers in $O(m)$ time?

Sorting $m$ Integers in $O(m)$ time is only possible if the input is already in a specific format, such as a list or array. If the input is in a different data structure, such as a tree or graph, it may not be possible to achieve $O(m)$ time complexity.

What are some commonly used algorithms for sorting $m$ Integers in $O(m)$ time?

Some commonly used algorithms for sorting $m$ Integers in $O(m)$ time include Counting Sort, Radix Sort, and Bucket Sort. These algorithms have linear time complexity and are often used for sorting large sets of integers efficiently.

Is sorting $m$ Integers in $O(m)$ time always the best approach?

No, sorting $m$ Integers in $O(m)$ time may not always be the best approach. It depends on the specific requirements and constraints of the problem at hand. For example, if the input is already nearly sorted, it may be more efficient to use a different sorting algorithm with a lower time complexity.

Similar threads

Replies
1
Views
1K
Replies
20
Views
4K
Replies
17
Views
4K
Replies
3
Views
2K
Replies
1
Views
1K
Replies
4
Views
4K
Replies
5
Views
4K
Back
Top