Finding the time complexity of a recursive algorithm

Question

I was solving a few problems related to finding the time complexity of algorithms and came across this question. It gave me a real hard time figuring what could possibly be the time complexity of this function. The image of the code snippet is attached below. Could somebody please help me understand the same and brief me about how to approach these types of problems? Many thanks in advance!

PS- Please don't mark this question as a duplicate!

Answer 1

The simple case: Assuming the array only has distinct elements

Thanks to the assumption, the last line return search...() + 1 + search...() can be executed at most once during the execution.

Hence, at every recursive call, the size of the search region in the array is divided by 2 (and subtracted 1); except at most once where there are two recursive calls instead of just 1.

When the search region reaches size 0, execution ends.

Initially, the search region has size N : it is the whole array.

How many times can we divide N by 2 before it reaches the value 1 , and then 0 thanks to the subtraction by 1?

This problem is well-known because it happens so often in algorithms; and the answer is, about log2(N) .

So there will be at most log2(N) recursive calls, except once where execution might split into recursive calls; hence there will be between log2(N) and 2 log2(N) recursive calls. Each recursive call is constant-time; hence the total time of execution is Θ(log(N)) .

A degenerate case: All elements are equal to k

In this case, none of the two if conditions V[mid] </> k will ever be true; hencewe will always fall in either the first case ( return 0 ) or the last case ( return ... + 1 + ... ).

In that case, the final return value of the function will be N , since the function is counting the number of occurrences of k in the array. Since the return value is only built by the +1+ , there must be exactly N calls which contribute a +1+ each; and of the two recursive calls triggered, at most two immediately return 0; so the total number of recursive calls must be at least N and at most 3*N . Hence the complexity is Θ(N) .

The "general" case

There might be more than 1 occurrence of k in the array. For the same reasons as presented before, the complexity of the algorithm should be Θ(K + log(N)) , where K is the number of occurrences of K and N is the size of the array. This is Θ(log(N)) in the best case, and Θ(N) in the worst case. As a summary, it is O(N) .

Average complexity

If we make the assumption that the input array is generated at random following a known probability distribution, then we could calculate the expected value of the complexity. This is usually referred to as "the average complexity". It would much harder to calculate exactly, and in this case, it looks like the probability distribution in the assumption would play a huge role, so different distributions would result in different average complexities. For instance, if the array is filled with N numbers taken independently, uniformly at random in range [0, 10^N] then the probability that k occurs more than once in the array is extremely low, so I would guess the expected complexity in that case to be close to log(N) . However, if the N numbers were taken at random in range [0, 10], then you can expect one tenth of the numbers to be equal to k , so the average complexity would be close to Θ(N/10) = Θ(N) .

An "average complexity" is often calculated for the algorithm Quicksort , assuming a list shuffled uniformly at random. Quicksort's worst-case complexity is Θ(N); its best-case complexity is Θ(log(N)). Its average complexity assuming a list shuffled uniformly at random is Θ(log(N)). This is "proven" in many computer science textbooks. However, so far all textbooks I have read on the subject were somewhat hand-wavy at some point or another; I haven't found a single book which handled the proof in a truly convincing way, with the rigour one would expect from a mathematical proof.