First, note that the variable n has no defined meaning in the context of this problem, so it makes no sense to express the runtime of your algorithm as a function of n.
Secondly, note that your algorithm only has reasonable terminating behavior if
- a and b are positive OR
- even for the initial a, b we have a + b > min{c, d}
The latter case is not particularly interesting, so let's concentrate on the former case. In particular we have a, b >= 1 in this case.
The pair (c, d) stays fixed during every recursion, so let's see what the nature of the pairs (a, b) is that your algorithm enumerates. Let A and B be the initial values of a and b. We have that in every function call, (a, b) = (x1 * A + y1 * B, x2 * A + y2 * B). The transitions are
((x1 + x2) * A + (y1 + y2) * B, x2 * A + y2 * B)
(x1 * A + y1 * B, (x1 + x2) * A + (y1 + y2) * B)
We can show that the function f(x1, y1, x2, y2) = (x1 + x2, y1 + y2) is injective when restricted to the values (x1, y1, x2, y2) that occur during the execution of the algorithm.
If we look at the complete recursion tree, without the prunings, f adopts the following values:
(1,1)
(1,2)
(1,3)
...
(2,1)
(2,3)
(2,5)
(2,7)
...
(3,1)
(3,2)
(3,4)
(3,5)
(3,7)
...
Notice the pattern? We can show that f adopts exactly the value pairs (x,y) with gcd(x,y) = 1 (the coprime pairs). Furthermore, because of the pruning, we only enumerate those pairs (x,y) with Ax + By <= min{c,d}. The runtime T of your algorithm, expressed as a function of A, B, c and d is thus
At this point I'm not sure how to establish the asymptotics of this function precisely. A quick-and-dirty upper bound that one gets after removing the co-primeness constraint and the floors, is T(A, B, c, d) = O(min{c,d}^2 / (A * B)) = O(min{c,d}^2). Not sure how tight this bound is.
UPDATE: In your CR post, you propose a much better algorithm to solve the problem. It still contains a bug, but it's a good start:
public static String betterSolution(int a, int b, int c, int d){
while( c > a || d > b){
if(c > d){
if (d == 0) break; // otherwise, it does not terminate!
c = c-d;
}else{
if (c == 0) break; // otherwise, it does not terminate!
d = d-c;
}
}
if( c == a && d == b){
return "Able to generate";
}else{
return "Not able to generate";
}
}
This algorithm is still only polynomial in the variables, O(max{c,d}) to be precise. You can improve it to logarithmic time by "skipping" over steps:
public static String evenBetterSolution(int a, int b, int c, int d){
while( c > a || d > b){
if(c > d){
if (d == 0) break;
c = c - Math.max(1, (c - a) / d) * d;
}else{
if (c == 0) break;
d = d - Math.max(1, (d - b) / c) * c;
}
}
if( c == a && d == b){
return "Able to generate";
}else{
return "Not able to generate";
}
}
The algorithm is based on the Euclidean GCD algorithm and the runtime is bounded by O(log(min{c,d})). Very good.