Maybe I'm mistaken in my understanding of Big-O notation (it has been a while since I've taken a course on algorithms) but the following has never made too much sense to me:

This would be considered O(n^2):

```
for (int i = 0; i < num_1; i++)
{
    for (int j = 0; j < num_2; j++) 
    {
        cout << i << " " << j << endl;
    }
}

```

This would be considered O(n):

```
for (int z = 0; z < num_3; z++) { cout << z << endl; }

```

My issue is when it comes to practical terms. Lets assume that `num_1 = 10; num_2 = 20; num_3 = 1000;`. In this case the first example, an O(n^2), would run considerably less iterations of it's interior than the O(n) second example.

In more general terms: when `num_3 > num_1 * num_2` then the O(n^2) snippet does less than the O(n) snippet. In real world applications, these two snippets may be doing two very separate tasks where there are functional bounds on `num_1`, `num_2`, and `num_3` are considerably different. The nested `num_1` and `num_2` may be looping variable values between 0 and 255 but `num_3` may frequent values above a million.

Why should/would a coder trust an algorithm or snippet based on its Big-O notation when it doesn't take into consideration the *practical* or *operational* variable boundaries?