That's right, if there's a limit on n, then your algorithm is O(n). I took some downvotes when I made this point on StackOverflow: http://stackoverflow.com/questions/1586858/find-the-smallest...
n as 12 makes a lot of sense. n as a number too large to count doesn't make sense in the context of real programs.
The formal definition of time complexity measures relative to the size of the input, which in this case would be proportional to the number of elements in the list.
> n as a number too large to count doesn't make sense in the context of real programs
The definition of big-O notation involves taking the limit as n goes to infinity. It doesn't really even make sense if you only have a finite (even if huge) number of problem instances, since then everything is bounded by a constant.
More importantly, you ignore the nature of the problem when you treat 2^64 as a constant, but the number of values in the list as n. I'm comfortable betting that if you take this problem, and push n to 2^100, you'll find that your integer size has been changed to 2^128. In other words, iconjack's algorithm is actually O(n) space or worse.
It's not obfuscation, it's literally the definition.
I'm not saying that the algorithm in question is practical, but asymptotic complexity has a precise mathematical definition, so it's totally possible for an algorithm with "good" time complexity to be so complicated or have such a huge constant that it's impossible to use (see [1] and [2] for some examples).
It's also totally legitimate to give a constraint on additional memory size, so that this algorithm is disallowed altogether (which is probably the right answer), or change the problem so that the word size varies with the list length, but it's not legitimate to just say that the algorithm isn't linear time because the constant is too big.
[1] http://cstheory.stackexchange.com/questions/4491/powerful-al...
[2] https://rjlipton.wordpress.com/2010/10/23/galactic-algorithm...
It does not talk about smaller numbers at all.
If you use an algorithm and complexity that are close for both moderately large numbers and extremely large numbers, you've done a good job.
If you introduce dumb things like constants that are larger than the known universe, you are performing obfuscation.
The suggested algorithm is linear, but only when applied to a very specific interpretation of the problem. I'm disagreeing with that interpretation of the problem, not the conclusion that it's linear within that particular interpretation.