Distinct digit count

Question

Is is possible to count the distinct digits in a number in constant time O(1)?

Suppose n=1519 output should be 3 as there are 3 distinct digits(1,5,9).

I have done it in O(N) time but anyone knows how to find it in O(1) time?

You have to visit each digit. Constant means you would use the same time to calculate n=1 as you would n=123456789 — Sotirios Delimanolis, Mar 12 '13 at 13:17
cheating on input (assuming time needed to split the string and transform it into a set can be left out of the game) — BigMike, Mar 12 '13 at 13:20
O(N) for what N? magnitude of n? number of digits (i.e. log)? — Kevin, Mar 12 '13 at 13:20
Precalculate all the values, then you can look up the result in O(1) with a simple indexing operation :) — Jon Skeet, Mar 12 '13 at 13:21
For a limited boundary, it is possible: build a List> list, that holds the digits in the list inside, and you can be in O(1) as long as your memory lasts... — ppeterka, Mar 12 '13 at 13:21
Also, I have a new idea... For radix 2, you can have it in O(1) :) :) :) :) For _all_ numbers! (insert epic evil genius laugh here) — ppeterka, Mar 12 '13 at 13:23
@ppeterka: Jon Skeet is like Chuck Norris, he attacks sharks when he smells them bleed :) — Andrea Ligios, Mar 12 '13 at 13:44
Store the numbers in base 10^N, thus you have only one "digit" and your answer is one. — Déjà vu, Mar 14 '13 at 08:40

score 6 · Answer 1 · answered Mar 12 '13 at 13:40

I assume N is the number of digits of n. If the size of n is unlimited, it can't be done in general in O(1) time.

Consider the number n=11111...111, with 2 trillion digits. If I switch one of the digits from a 1 to a 2, there is no way to discover this without in some way looking at every single digit. Thus processing a number with 2 trillion digits must take (of the order of) 2 trillion operations at least, and in general, a number with N digits must take (of the order of) N operations at least.

However, for almost all numbers, the simple O(N) algorithm finishes very quickly because you can just stop as soon as you get to 10 distinct digits. Almost all numbers of sufficient length will have all 10 digits: e.g. the probability of not terminating with the answer '10' after looking at the first 100 digits is about 0.00027, and after the first 1000 digits it's about 1.7e-45. But unfortunately, there are some oddities which make the worst case O(N).

If the given number fits in the underlying machine word, you have a trivial O(1) algorithm; namely look the answer up in a lookup table as suggested (tongue in cheek) by Jon Skeet. For general sized N, my point remains I think. — Simon Nickerson, Mar 12 '13 at 21:06
I'm sorry, I don't get your point. Whatever the word size is, it will be some fixed finite size. So the big-Oh performance of any algorithm that has to deal with arbitrary-sized data is going to be independent of the size of the word. Doing arithmetic on the words doesn't help, even if such operations can be done in O(1) per-word, because the number of words required to express the number n is itself O(N). — Simon Nickerson, Mar 13 '13 at 08:25

ppeterka · Answer 2 · 2013-03-14T08:32:30.457

After seeing that someone really posted a serious answer to this question, I'd rather repeat my own cheat here, which is a special case of the answer described by @SimonNickerson:

O(1) is not possible, unless you are on radix 2, because that way, every number other than 0 has both 1 and 0, and thus my "solution" works not only for integers...

EDIT

How about 2^k - 1? Isn't that all 1s?

Drat! True... I should have known that when something seems so easy, it is flawed somehow... If I got the all 0 case covered, I should have covered the all 1 case too.

Luckily this case can be tested quite quickly (if addition and bitwise AND are considered an O(1) operation): if x is the number to be tested, compute y this way: y=(x+1) AND x. If y=0, then x=2^k - 1. because this is the only case when all the bits needed to be flipped by the addition. Of course, this is quite a bit flawed, as with bit lengths exceeding the bus width, the bitwise operators are not O(1) anymore, but rather O(N).

At the same time, I think it can be brought down to O(logN), by breaking the number into bus width size chunks, and AND-ing together the neighboring ones, repeating until only one is left: if there were no 0s in the number tested, the last one will be full 1s too...

EDIT2: I was wrong... This is still O(N).

Drat! True... I should have known that when something seems so easy, it is flawed somehow... If I got the all 0 case covered, I should have covered the all 1 case too. Luckily this case can be tested quite quickly (if addition and bitwise AND are considered an O(1) operation): if x is the number to be tested, compute y this way: `y=(x+1) AND x`. If `y=0`, then `x=2^k - 1`. because this is the only case when all the bits needed to be flipped. Of course, this is quite a bit flawed, as with bit lengths exceeding the bus width, the bitwise operators are not O(1) anymore, but rather O(N)... — ppeterka, Mar 13 '13 at 20:46

Distinct digit count

2 Answers2