7

I was asked this question in an interview: Assume an infinite array of integers which is sorted. How would you search for an integer in this array? What would be time complexity? I guessed what the interviewer meant by infinite is that we dont know the value of 'n', where n is the index of the largest number in the array. I gave the following answer:

SEARCHINF(A,i,x){ // Assume we are searching for x
if (A(1) > x){
   return
}
if(A(i) == x){
   return i;
}
else{
    low = i;
    high = power(2,i);
    if (A(i)>x){
       BINARY-SEARCH(A,low,high);
    }
    else{
        SEARCHINF(A,high,x);
    }
}// end else
}// end SEARCHINF method

This will find the bound(low and high) in (log x + 1) time in the worst case, when the sorted numbers start from 1 and subsequent numbers are consequent. Then the binary search requires: 

O( log {2^(ceil(log x)) - 2^(floor(log x))} )

Is this correct? If correct, can this be optimized?

LostLin
  • 7,762
  • 12
  • 51
  • 73
Brahadeesh
  • 2,245
  • 8
  • 40
  • 58
  • Worst-case performance is pretty bad. It will take infinite time to determine if an item is larger than the largest item in the list. – Jim Mischel Mar 16 '11 at 18:48
  • I could not help it. I mean, we dont know the last index. Is there any way to determine this faster? – Brahadeesh Mar 16 '11 at 18:51

2 Answers2

4

Using the method of double your index until you pass it, then binary search the region you just jumped over (what it looks like your pseudocode is trying to do), the time spent should be O(log2 n) where n is the index of the item you are searching for.

It will take you (log2 n) tries to find the correct region, and then ((log2 n) - 1) tries to find x within that region (since you already searched from 0..n/2, you only need to search n/2..n). Therefore, O(log2 n + log2 n - 1) = O(log2 n).

However, if the "infinite array" does not contain x or any value greater than x, you will never know, because you will search forever.

Jonathan
  • 13,354
  • 4
  • 36
  • 32
  • Hi. Since we dont know the index of x, shouldnt we use x in place of n? I mean the worst index x can have is x itself. Hence I used x. – Brahadeesh Mar 17 '11 at 03:25
  • @Brahadeesh What about duplicates? 1, 1, 1, 1, 1, 2, ...? – Jonathan Mar 17 '11 at 13:20
  • Oh. I am sorry I forgot to mention. After some time, I was busy in writing the pseudo code, the guy asked me to assume no duplicates. – Brahadeesh Mar 17 '11 at 14:34
  • 1
    Well, then you can simply binary search the region [0, x], since you know that x (the index) cannot be smaller than x (the value you are searching for). Still O(log2 n) (although now n = x). – Jonathan Mar 17 '11 at 14:50
1

The sorted array gives it away indeed: binary sort.

Worst case scenario: O(lg(n)). There's no faster, assured way of finding it.

Of course, you could just tell him that finding an element in an infinite array will take forever.

Carra
  • 17,808
  • 7
  • 62
  • 75
  • If I remember my math well, that's also forever :) – Carra Mar 16 '11 at 19:15
  • for binary sort, dont we need to know the index of the middle element? and n is undefined for this problem. So, i guess, you have to express the running time in x. – Brahadeesh Mar 16 '11 at 19:17