# Easy interview question got harder: given numbers 1..100, find the missing number(s) given exactly k are missing

Asked  7 Months ago    Answers:  5   Viewed   12 times

I had an interesting job interview experience a while back. The question started really easy:

Q1: We have a bag containing numbers `1`, `2`, `3`, …, `100`. Each number appears exactly once, so there are 100 numbers. Now one number is randomly picked out of the bag. Find the missing number.

I've heard this interview question before, of course, so I very quickly answered along the lines of:

A1: Well, the sum of the numbers `1 + 2 + 3 + … + N` is `(N+1)(N/2)` (see Wikipedia: sum of arithmetic series). For `N = 100`, the sum is `5050`.

Thus, if all numbers are present in the bag, the sum will be exactly `5050`. Since one number is missing, the sum will be less than this, and the difference is that number. So we can find that missing number in `O(N)` time and `O(1)` space.

At this point I thought I had done well, but all of a sudden the question took an unexpected turn:

Q2: That is correct, but now how would you do this if TWO numbers are missing?

I had never seen/heard/considered this variation before, so I panicked and couldn't answer the question. The interviewer insisted on knowing my thought process, so I mentioned that perhaps we can get more information by comparing against the expected product, or perhaps doing a second pass after having gathered some information from the first pass, etc, but I really was just shooting in the dark rather than actually having a clear path to the solution.

The interviewer did try to encourage me by saying that having a second equation is indeed one way to solve the problem. At this point I was kind of upset (for not knowing the answer before hand), and asked if this is a general (read: "useful") programming technique, or if it's just a trick/gotcha answer.

The interviewer's answer surprised me: you can generalize the technique to find 3 missing numbers. In fact, you can generalize it to find k missing numbers.

Qk: If exactly k numbers are missing from the bag, how would you find it efficiently?

This was a few months ago, and I still couldn't figure out what this technique is. Obviously there's a `?(N)` time lower bound since we must scan all the numbers at least once, but the interviewer insisted that the TIME and SPACE complexity of the solving technique (minus the `O(N)` time input scan) is defined in k not N.

So the question here is simple:

• How would you solve Q2?
• How would you solve Q3?
• How would you solve Qk?

### Clarifications

• Generally there are N numbers from 1..N, not just 1..100.
• I'm not looking for the obvious set-based solution, e.g. using a bit set, encoding the presence/absence each number by the value of a designated bit, therefore using `O(N)` bits in additional space. We can't afford any additional space proportional to N.
• I'm also not looking for the obvious sort-first approach. This and the set-based approach are worth mentioning in an interview (they are easy to implement, and depending on N, can be very practical). I'm looking for the Holy Grail solution (which may or may not be practical to implement, but has the desired asymptotic characteristics nevertheless).

So again, of course you must scan the input in `O(N)`, but you can only capture small amount of information (defined in terms of k not N), and must then find the k missing numbers somehow.

10

Here's a summary of Dimitris Andreou's link.

Remember sum of i-th powers, where i=1,2,..,k. This reduces the problem to solving the system of equations

a1 + a2 + ... + ak = b1

a12 + a22 + ... + ak2 = b2

...

a1k + a2k + ... + akk = bk

Using Newton's identities, knowing bi allows to compute

c1 = a1 + a2 + ... ak

c2 = a1a2 + a1a3 + ... + ak-1ak

...

ck = a1a2 ... ak

If you expand the polynomial (x-a1)...(x-ak) the coefficients will be exactly c1, ..., ck - see Viète's formulas. Since every polynomial factors uniquely (ring of polynomials is an Euclidean domain), this means ai are uniquely determined, up to permutation.

This ends a proof that remembering powers is enough to recover the numbers. For constant k, this is a good approach.

However, when k is varying, the direct approach of computing c1,...,ck is prohibitely expensive, since e.g. ck is the product of all missing numbers, magnitude n!/(n-k)!. To overcome this, perform computations in Zq field, where q is a prime such that n <= q < 2n - it exists by Bertrand's postulate. The proof doesn't need to be changed, since the formulas still hold, and factorization of polynomials is still unique. You also need an algorithm for factorization over finite fields, for example the one by Berlekamp or Cantor-Zassenhaus.

High level pseudocode for constant k:

• Compute i-th powers of given numbers
• Subtract to get sums of i-th powers of unknown numbers. Call the sums bi.
• Use Newton's identities to compute coefficients from bi; call them ci. Basically, c1 = b1; c2 = (c1b1 - b2)/2; see Wikipedia for exact formulas
• Factor the polynomial xk-c1xk-1 + ... + ck.
• The roots of the polynomial are the needed numbers a1, ..., ak.

For varying k, find a prime n <= q < 2n using e.g. Miller-Rabin, and perform the steps with all numbers reduced modulo q.

EDIT: The previous version of this answer stated that instead of Zq, where q is prime, it is possible to use a finite field of characteristic 2 (q=2^(log n)). This is not the case, since Newton's formulas require division by numbers up to k.

Tuesday, June 1, 2021

answered 7 Months ago
38

You got off lightly, you probably don't want to be working for a hedge fund where the quants don't understand basic algorithms :-)

There is no way to process an arbitrarily-sized data structure in `O(1)` if, as in this case, you need to visit every element at least once. The best you can hope for is `O(n)` in this case, where `n` is the length of the string.

Although, as an aside, a nominal `O(n)` algorithm will be `O(1)` for a fixed input size so, technically, they may have been correct here. However, that's not usually how people use complexity analysis.

It appears to me you could have impressed them in a number of ways.

First, by informing them that it's not possible to do it in `O(1)`, unless you use the "suspect" reasoning given above.

Second, by showing your elite skills by providing Pythonic code such as:

``````inpStr = '123412345123456'

# O(1) array creation.
freq = [0] * 1000

# O(n) string processing.
for val in [int(inpStr[pos:pos+3]) for pos in range(len(inpStr) - 2)]:
freq[val] += 1

# O(1) output of relevant array values.
print ([(num, freq[num]) for num in range(1000) if freq[num] > 1])
``````

This outputs:

``````[(123, 3), (234, 3), (345, 2)]
``````

though you could, of course, modify the output format to anything you desire.

And, finally, by telling them there's almost certainly no problem with an `O(n)` solution, since the code above delivers results for a one-million-digit string in well under half a second. It seems to scale quite linearly as well, since a 10,000,000-character string takes 3.5 seconds and a 100,000,000-character one takes 36 seconds.

And, if they need better than that, there are ways to parallelise this sort of stuff that can greatly speed it up.

Not within a single Python interpreter of course, due to the GIL, but you could split the string into something like (overlap indicated by `vv` is required to allow proper processing of the boundary areas):

``````    vv
123412  vv
123451
5123456
``````

You can farm these out to separate workers and combine the results afterwards.

The splitting of input and combining of output are likely to swamp any saving with small strings (and possibly even million-digit strings) but, for much larger data sets, it may well make a difference. My usual mantra of "measure, don't guess" applies here, of course.

This mantra also applies to other possibilities, such as bypassing Python altogether and using a different language which may be faster.

For example, the following C code, running on the same hardware as the earlier Python code, handles a hundred million digits in 0.6 seconds, roughly the same amount of time as the Python code processed one million. In other words, much faster:

``````#include <stdio.h>
#include <string.h>

int main(void) {
static char inpStr[100000000+1];
static int freq[1000];

// Set up test data.

memset(inpStr, '1', sizeof(inpStr));
inpStr[sizeof(inpStr)-1] = '';

// Need at least three digits to do anything useful.

if (strlen(inpStr) <= 2) return 0;

// Get initial feed from first two digits, process others.

int val = (inpStr[0] - '0') * 10 + inpStr[1] - '0';
char *inpPtr = &(inpStr[2]);
while (*inpPtr != '') {
// Remove hundreds, add next digit as units, adjust table.

val = (val % 100) * 10 + *inpPtr++ - '0';
freq[val]++;
}

// Output (relevant part of) table.

for (int i = 0; i < 1000; ++i)
if (freq[i] > 1)
printf("%3d -> %dn", i, freq[i]);

return 0;
}
``````
Saturday, August 7, 2021

answered 4 Months ago
100

It is easy to see if you do some runs and print the successive values of x and y. For example for 100:

``````50.5 1.9801980198019802
26.24009900990099 3.8109612300726345
15.025530119986813 6.655339226067038
10.840434673026925 9.224722348894286
10.032578510960604 9.96752728032478
10.000052895642693 9.999947104637101
10.000000000139897 9.999999999860103
``````

See, the trick is that if `x` is not the square root of `n`, then it is above or below the real root, and `n/x` is always on the other side. So if you calculate the midpoint of `x` and `n/x` it will be somewhat nearer to the real root.

And about the complexity, it is actually unbounded, because the real root will never reached. That's why you have the `e` parameter.

Sunday, August 29, 2021

answered 3 Months ago
38

How about an evolutionary algorithm.

Start with a guess. 1 thread per CPU core seems good, but depends on the task at hand.

Measure the average time for each task in the generation. Compare it to the time taken by the previous generation. (Assume effectively infinite time and 0 threads for generation 0).

If the most recent generation tasks averaged a better time than the one before, continue to change the number of threads in the same direction as you did last step (so if the last generation had more threads than the previous thread, then add a thread for the new generation, but if it had fewer, then use one fewer (obviously with a lower limit of 1 thread).

If the most recent generation tasks took longer, on average, than the previous generation, then change the number of threads in the opposite direction (so if increasing the number of threads resulted in worse time, use one fewer thread next time).

As long as the optimal number of threads isn't too close to 1, then you'll probably end up oscillating between 3 values that are all reasonably close to optimal. You may want to explicitly detect this case and lock yourself into the central value, if you have a large number of generations to deal with.

Saturday, November 13, 2021

answered 3 Weeks ago
54

You can broadcast `ismissing` with `.`:

``````julia> v = [1, 2, missing, 4]
4-element Array{Union{Missing, Int64},1}:
1
2
missing
4

julia> ismissing.(v)
4-element BitArray{1}:
false
false
true
false
``````
Tuesday, November 16, 2021

answered 3 Weeks ago