1

Given the following algorithm :

    input : a (integer), b (integer != 0)

    result = 0;
    while(a >= b) 
    {
       a = a - b;
       result = result + 1;
    }

    return result;

How to find the number of instructions and the time complexity of this kind of algorithm since we don't know neither a nor b nor the number of iteration in advance ?

Spn
  • 133
  • 4
  • 1
    Possible duplicate of Is there a system behind the magic of algorithm analysis? – David Richerby Oct 07 '18 at 17:30
  • What did you try? Where did you get stuck? We prefer to answer questions, rather than solve homework-style exercises, because then we can explain and teach and help. – David Richerby Oct 07 '18 at 17:32
  • @DavidRicherby You are right. I've prefered to ask the question directly because I've already asked it in a different way, but got confusing answer and flagged for duplicate subject. So I've prefered to be straight. In fact I just wanted a methodology for this "kind" of algorithm. Your link provides me good informations, but I'm still struggling with this simple algorithm where we don't know the entries. My method with the summations doesn't work here. I tried with random a,b, and found a pattern with a/b but I should rather have something like O(n) so I'm trying to fix n. It confuses me – Spn Oct 07 '18 at 18:06
  • What is "$n$"? There's no $n$ in your question. – David Richerby Oct 07 '18 at 18:07

2 Answers2

1

Your algorithm makes exactly $\lfloor\frac{a}{b}\rfloor$ iterations of while loop.

If we suppose that the size of the inputs is $n=max\{a,b\}$ then your algorithm will make at most $n$ iterations; when $a=n$ and $b=1$.

Therefore, with this notation, your algorithm (on a high level) runs in $O(n)$ time complexity.

If you want to analyze it deeper, including the complexity of addition and subtraction which are $\Theta(n)$ for $n$-digit numbers, things get more complicated because $n$ we defined above was not the number of digits (decimal representation) but a value (unary representation).
As it can be shown, the base in which we represent numbers is not relevant, so the overall analyzed algorithm, having in mind also the properties of big-O and big-Theta runs in $O(n^2)$ where $n$ is the number of digits (in any base).

Sandro Lovnički
  • 1,191
  • 1
  • 6
  • 17
  • Can you tell me step by step the methodology that you followed ? If I correctly understood : you first guessed the number of iterations, which is a/b. And then, you searched for n = max{a,b} and you find out that when a is the maximum and b is 1 (which is the minimum it can take), then the time complexity in worst case become |_ n/1 _| which mean n times. Therefore it's O(n).

    Am I correct ? We should first guess the number of iterations, and then compute with the variables to find the worst case possible and deduce the time complexity.

     – Spn Oct 07 '18 at 16:47
  • I think you are on the right path, but it is not the case that I guessed that it takes a/b steps. Given a and b, it must take exactly a/b steps. Think about it. Then the n... in order to speak about complexity, we must fix some measure od length of the input and it must be just one number. It is usual to name it n. I was just thinking about couple of examples how your code would run, intuitively had a feeling that it is O(n) and then it came to me that max{a,b} would be a good definition of measure to go along with the result. This is the thinking procedure I would say I followed. – Sandro Lovnički Oct 07 '18 at 17:01
  • @Spn See the links I put in my edited answer, it might be of some help. – Sandro Lovnički Oct 07 '18 at 17:03
0

As your while is run in $\frac{a}{b}$-times, and inside your loop there just an add and subtraction, the time complexity is $\Theta(\frac{a}{b})$.

OmG
  • 3,572
  • 1
  • 14
  • 23