2

If we had a case where we are looping over the array of numbers and the numbers can scale to infinity, and inside of each iteration we are looping over digits of each number, so for number 125556 we would loop through six numbers, 1, 2, 5, 5, 5, and 6, is the time complexity of this algorithm just O(N), where N represents the numbers in the array, or it is O(N*K) where K is the number of digits in the number. In this case K is always less than N, so I am unclear whether this is multiplication or we can just disregard the number of digits?

SrdjaNo1
  • 755
  • 3
  • 8
  • 18
  • 1
    If "numbers can scale to infinity", then K is infinity (and *not* less than N, as you claim), and N really doesn't matter. – Scott Hunter Mar 17 '22 at 15:41
  • But N is always greater than K, so is this O(N*K) then since we are talking about different data sets? – SrdjaNo1 Mar 17 '22 at 15:42
  • If "numbers can scale to infinity", *nothing* is greater than K. – Scott Hunter Mar 17 '22 at 15:43
  • Not sure why you're saying that N is always greater than K. The array could be of length N=1 and contain the single number 12556 (K=5). – Raymond Chen Mar 17 '22 at 18:46
  • @RaymondChen It can't as I haven't fully explained problem to simplify it. You are looping from 1 to the given number and then performing some math on the digits of the number. So if the number is `99999999` , you are always looping from `1` to `99999999` – SrdjaNo1 Mar 18 '22 at 19:07
  • Oh, so there is no array at all. You're just looping over the numbers from 1 to N. – Raymond Chen Mar 18 '22 at 20:36
  • @SrdjaNo1 I had not understood that you loop over them in sequence. I updated my answer accordingly. – Berthur Mar 18 '22 at 21:56

1 Answers1

1

The algorithm you describe is always O(N * K).

However, if you know something about the relationship between N and K, then you can simplify the expression. For instance, if the numbers are guaranteed to fit in a 32-bit integer representation on a computer, then K is a constant and your algorithm is O(N). If K < N, then you can say O(N2).

But if you have no assumption on K, then you have to go with O(N * K), as K could be significantly larger than N or vice versa. Intuitively, your time complexity depends on two factors, so you need to express it with two variables unless they depend on each other.

Edit:

Since you clarified that you are looping through the numbers in order, as in 1, 2, ..., N, we now have some information on the relationship between K and N. In fact, K = O(logN), so the algorithm can be expressed as O(N logN).

If you are confused about how we know that K = O(logN), then take any power of 10 as an example. You will find that 10K has log10 10K + 1 = K + 1 digits. Similarly, any number X has O(log X) decimal digits (notice that the base of the logarithm does not matter in the big-O notation).

Berthur
  • 4,300
  • 2
  • 14
  • 28
  • Note that dividing by 10 is also a `log N` operation. It's just that most of the time we treat division as O(1) because we assume the values all fit into a single register. Since this question assumes that N is large enough that you need to worry about the number of digits in the answer, you may also have to worry about the cost of division too. – Raymond Chen Mar 19 '22 at 15:53
  • @RaymondChen Ok that's a good point. But with random access, we can still do it in O(N logN), wouldn't you agree? E.g. by working in base 10 to begin with. (In practice, represent our increasing number by an array of decimal elements.) – Berthur Mar 21 '22 at 14:14
  • If you pick a representation where each number is (number of digits)(array of digits), then you can add up the number of digits in an array in O(N) by just adding the "number of digits" and ignoring the array. But again, addition of very large numbers is O(log N), not O(1), so you may have to take that into account. Also, remember that we don't have an array (so "random access" means nothing); we are counting from 1 to N. Really: The answer can be calculated in closed form by sitting down and doing some math. – Raymond Chen Mar 21 '22 at 14:19