find an element in a sorted matrix [duplicate]

Answer 1

Start in the bottom-left corner of your matrix. Then go to the right until you find the exact number (done), or until you find a number that is bigger.

Then you go upwards in the matrix until you find the exact number (done), or until you find a number that is too small.

Then again you move to the right, ... and so on until you found the number or until you reach the right-side or top of your matrix.

The following images contain some examples, using an Excel table showing the target number in green, and the path that is followed in yellow.

In the last example we look for 207, which isn't in the matrix:

This is just the algorithm. The coding is left for you as an exercise :-)

EDIT: When starting on the bottom row, a binary search might give a better starting point. For the rest of the algorithm it probably doesn't matter.

Answer 2

I believe that your algorithm does not have the time bounds that you believe that it does.

To see this, for simplicity let's assume that your grid is an n x n square (let's call this size m). If I can derive a different time bound than O(log n) in this case, I can argue that what you have should not be correct.

In particular, notice that in the worst case you make three recursive calls to problems that are of size (n / 2) x (n / 2) = m / 4. This means that we have the recurrence

T(1) = 1
T(m) = 3T(m / 4) + O(1)

Using the Master Theorem, the runtime for this function would be O(m^log₄3) = O(n^{2 log₄3}) = O(n ^log₄9) ≈ O(n^1.5849625). This is ω(log n + log m); that is, it's asymptotically strictly greater.

As many other people have posted, there are several well-known algorithms that run in O(m + n) that are based by walking one step in the right direction at each step. Consequently, correctness aside, I would not advise using the algorithm you've posted.

Answer 3

Your algorithm may be O(log m + log n), but it also gives the wrong answer.

Suppose you search for "4" in the following matrix (where the upper-left is row=0, col=0):

0 1 4
1 2 5
2 3 6

Your algorithm starts by looking at the 2 in the center. Since 4 is greater than 2, you proceed to search the same row (not there), same column (not there), and the lower-right corner (not there). Whoops.

The constraint that each row and column is sorted is actually pretty weak. In particular, the elements along the diagonal could be in any order.

I think the correct approach is to do a binary search on the first and last column to narrow down a range of possible rows. Then do binary search on the first and last of those rows to narrow down the possible columns. And so forth.

Not sure how to analyze the performance of this one...

Answer 4

boolean FindElem(int[][] mat, int elem, int M, int N) {
 int row = 0;
 int col = N-1;
 while (row < M && col >= 0) {
   if (mat[row][col] == elem) {
     return true;
   } else if (mat[row][col] > elem) {
     col--;
   } else {
     row++;
   }
 }
   return false;
}

Answer 5

Given elements in 2d array(be a[n][m]) are increasing horizontally and vertically . So for the given question we need to find the index of the element first. So if we can find the element in quicker way then we can optimize the solution . The question is how do we find it in efficient way. One approach is take the middle element of the matrix and check given element with it

if given element is lesser than middle element then our solution lies in matrix a[0][0] to a[n/2][m/2] because all elements to right and below are greater than middle (since given element is less than middle element) so we have reduced our search space from a[n][m] to a[n/2][m/2] which is one fourth of original size.

if given element is greater than middle element then our solution doesnt lies in matrices a[0][0] to a[n/2][m/2] because all elements to left and above are lesser than middle (since given element is greater than middle element) so our search space is total array minus a[0][0] to a[n/2][m/2] which is three-fourth of original size. Total array minus a[0][0] to a[n/2][m/2] means ,there will be three recursive call with array index

--------->a[0][m/2](start index) to a[n/2][m](end index)  
--------->a[n/2][0](start index) to a[n][m/2](end index)
--------->a[n/2][m/2](start index) to a[n][m](end index)

Now recursively call the same function based on our search space.

Time complexity of our function will as follows . NOTE: In time function n represents total number of element but not no of rows as mentioned .n=(no_of_rows)*(no_of_columns)

                _________________T(n/4)  if given element is less than middle of the array.
               / 
              /
T(n)==========------------------- 1 if n=1 (if element found)
              \
               \_________________3T(n/4) if given element is greater than middle element of array

so out time function will

T(n)=3T(n/4) or T(n)=T(n/4)

In worst case T(n)=3T(n/4)
               T(n)=3{3T(n/4)}
               T(n)=3power(i)T(n/(4)poweri)     equation------> (1) 

But T(1)=1 (guessing given elemet is found in array)

so  n/(4power(i))=1
====> n=2power(2*i)
====> n=2power(2*i)
Talking log to base 2 on both sides (log[n])/2=i ====> i=log(sqrt(n))

substituting equation 1 we get

T(n)=3power(log[sqrt(n)])
T(n)∈ θ( nlog sqrt(3) )..

To my knowledge this is the algorithm that takes minimum number of comparisons.

Answer 6

For a comparison based algorithm, O(lg(m) + lg(n)) queries is optimal.

Proof

For a comparison based query, each query can only have two results: true or false. An obvious extension of this is that for N queries you can have at most 2^N results. Therefore, using N queries, you can only locate elements in a matrix with at most 2^N elements.

How many queries then are required to search an m x n matrix? Just solve for N.

2^N = mn
lg(2^N) = lg(mn)
N = lg(m) + lg(n)

Therefore lg(m) + lg(n) queries is optimal.

Non-comparison based queries

That proof is conclusive, but only for comparison based queries. If you query the matrix in a way that doesn't involve comparisons then you can get near-constant time if you know the distribution of values. I won't give you an algorithm, but I would suggest looking at Radix sort as it contains the kind of non-comparison based techniques that are required to beat the lg(m) + lg(n) lower bound.