Edit: I’ve been reading on SO for about 3 hours so far and it still isn’t making much sense to me (meaning I have done my research before asking). Forgot to state that in the OQ.
Alright, I’m completely at a loss with BigO and it makes almost no sense to me when trying to apply other methods of applying it to my code. If anyone can help, I’d like a walkthrough of how to calculate the BigO of the following.
int i = 0;
int t = 0;
while(i <= 4){
// Basic instructions
int s = 0;
while(s <= 4){
// Basic instructions
t + 2;
if(conditions){ // Checks if a value isn't in a hashset
for(int r = 0; r <= t; r++){
// Basic instructions
if(conditions){ // This statement can make t equal to any number < t, checks if two strings are identical.
// Do stuff
}else{
// Do stuff.
}
}
}else if(condition){
i++;
}
s++;
}
}
I can put the full code in there if needed, but as far as I can tell I think that should be enough to help me.
My thoughts so far were that (excluding if statements) the notation is something like O(n^3) but because they’re nested (and stuff others have told me) it’s kinda thrown me off a bit.
Please note: this isn’t directly for an assignment, but we’ve been given the task to talk about code we wrote for an assignment and it’s complexity. We’ve been told to show we understand complexity/correctness (in general, not BigO) and how it’s applied, but not to apply it to our code since it would be way too complicated to do. I’m only looking at doing this because I want to understand it better for the future. The above code is also a random example, not my actual code meaning I’d still have to change it to fit anyway.
Thanks in advance, we only looked at BigO for about 30 minutes in class and after a load of reading I think I confused myself too much. As I said, if that code isn’t appropriate I can change it.
If it’s not clear what N is, then you could calculate the performance with respect to all variables, and see which one makes more of a difference. In this case, the variables are i, s r and t. The performance strictly speaking is O(i * s * t). r is not included as it’s counting up to t, which is where the t in the big O comes from.
The issue though, is that since t cannot exceed 2*s, substituting t for 2s gives O(i * s * 2s). This is the same as O(2 * i * s^2). However, in big O notation all coefficients are treated as being equal to 1. Therefore, it becomes O(i * s^2). However, i and s cannot exceed 4, and since big O is only concerned about the worst case, it then becomes O(4 * 4^2), as big O is only concerned about the worst possible case. This simplifies to O(64). However, 64 is considered a coefficient*. Therefore, the actual big O is O(1)*.
*Note this isn’t strictly correct, as cases like O(x + 64) becomes O(x) and not O(x + 1), in this case, 64 actually becomes a zero not a one.
Meaning, the algorithm as it currently stands is O(1), which is essentially input independent. Which is why there is some confusion coming from the commenters.
The key take away here is that, you may have multiple input size variables, which affect the performance independently, you also might have a output-sensitive algorithm, which has a performance based both on size of the input and the size of the output. Or, you might have an algorithm that is unaffected by the input size.
For a more detailed explanation, see the Wikipedia page.