1

So i came upon this question where:

we have to sort n numbers between 0 and n^3 and the answer of time complexity is O(n) and the author solved it this way:

first we convert the base of these numbers to n in O(n), therefore now we have numbers with maximum 3 digits ( because of n^3 )

now we use radix sort and therefore the time is O(n)

so i have three questions :

1. is this correct? and the best time possible?

2. how is it possible to convert the base of n numbers in O(n)? like O(1) for each number? because some previous topics in this website said its O(M(n) log(n))?!

3. and if this is true, then it means we can sort any n numbers from 0 to n^m in O(n) ?!

( I searched about converting the base of n numbers and some said its O(logn) for each number and some said its O(n) for n numbers so I got confused about this too)

OneAndOnly
  • 1,048
  • 1
  • 13
  • 33
  • I declare it to be cheating to say that k=3 is a constant for _this_ algorithm, but require competing algorithms to use `log(n)` in their O() formulas. – Rick James Dec 20 '18 at 23:09

3 Answers3

2

1) Yes, it's correct. It is the best complexity possible, because any sort would have to at least look at the numbers and that is O(n).

2) Yes, each number is converted to base-n in O(1). Simple ways to do this take O(m^2) in the number of digits, under the usual assumption that you can do arithmetic operations on numbers up to O(n) in O(1) time. m is constant so O(m^2) is O(1)... But really this step is just to say that the radix you use in the radix sort is in O(n). If you implemented this for real, you'd use the smallest power of 2 >= n so you wouldn't need these conversions.

3) Yes, if m is constant. The simplest way takes m passes in an LSB-first radix sort with a radix of around n. Each pass takes O(n) time, and the algorithm requires O(n) extra memory (measured in words that can hold n).

So the author is correct. In practice, though, this is usually approached from the other direction. If you're going to write a function that sorts machine integers, then at some large input size it's going to be faster if you switch to a radix sort. If W is the maximum integer size, then this tradeoff point will be when n >= 2^(W/m) for some constant m. This says the same thing as your constraint, but makes it clear that we're thinking about large-sized inputs only.

Matt Timmermans
  • 53,709
  • 3
  • 46
  • 87
  • Thanks for the answer, so whenever we have a modern day computer can I assume that I can change the base of a number in O(1)? (because in exams they usually just ask us about what is the best time complexity we can get in solution of a problem and they don't give much detail about the computer and such) – OneAndOnly Apr 06 '18 at 14:48
  • Questions about the complexity of changing the base of a number are not usually about constant-sized numbers, so no, the answer is usually not O(1). Even here the bit about changing the base is unnecessary as I indicated. The author just did that because it's the easiest way to explain how the radix sort takes a constant number of passes. – Matt Timmermans Apr 06 '18 at 14:54
  • but I thought the radix sort's time complexity is O(nk) where k is the maximum number of digits we can have? I mean shouldn't we have a loop and repeat it k times in the algorithm therefore making this conversion necessary? sorry I didn't get the part where you said use the smallest power of 2 >= n – OneAndOnly Apr 06 '18 at 15:07
  • k=m, and m is constant in this case, so O(nk) = O(n) – Matt Timmermans Apr 06 '18 at 16:52
0

There is wrong assumption that radix sort is O(n), it is not.

As described on i.e. wiki:

if all n keys are distinct, then w has to be at least log n for a random-access machine to be able to store them in memory, which gives at best a time complexity O(n log n).

The answer is no, "author implementation" is (at best) n log n. Also converting these numbers can take probably more than O(n)

libik
  • 22,239
  • 9
  • 44
  • 87
  • The radix time complexity is O(k(n+m)) where k is the maximum number of digits and m is the base, and in this question when we convert the base, the maximum digits of our numbers become 3 since they were between 0 and n^3 and therefore radix sort will be O(n). I know this part for a fact but I don't get how is it possible to convert the base of n numbers in O(n) – OneAndOnly Apr 06 '18 at 10:30
  • @OneAndOnly If you need to convert the base of `n` numbers, it's by definition going to be O(n), because for every number you have an O(1) operation, repeated `n` times. The problem here is that the author does NOT have `n` numbers, but `n^3` and I don`t really see how switching base is going to improve anything. – ChatterOne Apr 06 '18 at 10:35
  • @ChatterOne no we actually have n numbers, between 0 and n^3 (my bad, I think the question was kinda vague which I fixed it), and how is that possible to convert a number to any base in O(1)? I tried googling and every stackoverflow topic they were talking about logn and such which got me confused? – OneAndOnly Apr 06 '18 at 10:37
  • @ChatterOne for example this topic where they say the complexity is O(M(n) log(n)) ! https://stackoverflow.com/questions/28418332/computational-complexity-of-base-conversion – OneAndOnly Apr 06 '18 at 10:39
  • @OneAndOnly re: converting base: in this sense, every basic arithmetic operation is log(n) where n = number of bits. libik talks about converting numbers of a fixed maximum size. – Vroomfondel Apr 06 '18 at 10:46
  • @OneAndOnly You're talking of O(M(n) log(n)) where n is the number of bits, I'm talking about `n` where `n` is the amount of numbers you have to convert. You don't need to do more passes on the same number to be able to convert it. – ChatterOne Apr 06 '18 at 10:50
  • @OneAndOnly - `where k is the maximum number of digits` - and what is the maximum number of digits? For `n` it is `log n`, therefore `k=log n` – libik Apr 06 '18 at 10:54
  • @libik but as the algorithm says, when we convert the base of these numbers to n, the maximum number of digits in any number will be 3, because the maximum number was n^3 (so after conversion it has maximum 3 digits in any number), my main doubt was the part where the base of n numbers is converted in O(n), what is your thought on that? is that correct? – OneAndOnly Apr 06 '18 at 11:00
  • @ChatterOne so overall the time to convert the base of n numbers to any base is O(n) and this algorithm will indeed solve the question in O(n) correct? – OneAndOnly Apr 06 '18 at 11:03
  • @Vroomfondel that bit part is really confusing me, for example is that a factor in our question here or not? like when we are converting the base of n numbers, shouldn't we also consider the number of bits in each number? doesn't that effect the time complexity of changing the base of n numbers and therefore making it more than O(n) ? – OneAndOnly Apr 06 '18 at 11:06
  • The assumption on the base conversion is that you are converting from machine words of size at least O(log n) bits, not that you are converting from a decimal string or something. Unless otherwise specified, complexity analysis generally assumes that the **size** of anything fits into a constant number of machine words. – Matt Timmermans Apr 06 '18 at 12:26
0
  1. is this correct?

Yes it's correct. If n is used as the base, then it will take 3 radix sort passes, where 3 is a constant, and since time complexity ignores constant factors, it's O(n).

and the best time possible?

Not always. Depending on the maximum value of n, a larger base could be used so that the sort is done in 2 radix sort passes or 1 counting sort pass.

  1. how is it possible to convert the base of n numbers in O(n)? like O(1) for each number?

O(1) just means a constant time complexity == fixed number of operations per number. It doesn't matter if the method chosen is not the fastest if only time complexity is being considered. For example, using a, b, c to represent most to least significant digits and x as the number, then using integer math: a = x/(n^2), b = (x-(a*n^2))/n, c = x%n (assumes x >= 0). (side note - if n is a constant, then an optimizing compiler may convert the divisions into a multiply and shift sequence).

  1. and if this is true, then it means we can sort any n numbers from 0 to n^m in O(n) ?!

Only if m is considered a constant. Otherwise it's O(m n).

rcgldr
  • 27,407
  • 3
  • 36
  • 61