0

I am to find the time complexity of my algorithm and I found one method here.
However I am really not sure about it correctness thus I would like to check it.
There is my algorithm (N is a set (len(N) is constant) and C is a number):

def f(N, C, k = 0):
    if C < 0:
        return 0
    if C == 0:
        return 1
    if not N:
        return 0
    i = 0
    for l in N:
        if l >= k:
            i += f(N, C - liczba, liczba)
    return i

And to my mind time complexity is equal to:
a+b+c+d+len(N)*C where a, b, c, d are constants.

Raphael
  • 72,336
  • 29
  • 179
  • 389
Hendrra
  • 101
  • 1
  • 1
    How did you arrive at that result? Have you tried a structured approach? – Raphael Jan 14 '17 at 22:33
  • I decided that each line of my code will be done in some time - those are a, b, c, d. Then we have the loop - l in N so len(N). And the function will be called (C - l) times. – Hendrra Jan 14 '17 at 22:37
  • 1
    @Hendrra As a matter of style, one would tend to merge all of those constants into one (the sum of a bunch of constants is just some other constant). However, the analysis is going to be much more complicated than you suggest, since each iteration of the loop makes a recursive call to f. (By the way, should liczba be l?) – David Richerby Jan 15 '17 at 11:30
  • Let m be the number of elements of N which are ≥ liczba. Each recursive call makes m recursive calls. The recursion will go about C / liczba levels deep, so the execution time is roughly m^(C / liczba). Looks like your algorithm is terribly, terribly inefficient, since the result can easily be found in time proportional to the number of elements of N plus C / liczba. – gnasher729 Jan 15 '17 at 13:01
  • Just run the algorithm with N = { 1, 2 }, liczba = 1, and C going from 1 to 100 and measure the time (hint: your computer will not finish this task). It seems you haven't done this, or you would never, ever have the idea that the time would be just linear in C * len (N). – gnasher729 Jan 15 '17 at 13:05

0 Answers0