It\'s quite easy to see that n! grows slower than almost anything to the N power (say, 100^N) and so, if a problems is considered NP complete and one happened upon a n! algorith
No. factorial time is not polynomial time. Polynomial time normally means an equation of the form O(Nk), where N = number of items being processed, and k = some constant. The important part is that the exponent is a constant -- you're multiplying N by itself some number of that's fixed -- not dependent on N itself. A factorial-complexity algorithm means the number of multiplications is not fixed -- the number of multiplications itself grows with N.
You seem to have the same problem here. N2 would be polynomial complexity. 2N would not be. Your basic precept is mistaken as well -- a factorial-complexity algorithm does not mean "we have a decently fast algorithm", at least as a general rule. If anything, the conclusion is rather the opposite: a factorial algorithm may be practical in a few special cases (i.e., where N is extremely small) but becomes impractical very quickly as N grows.
Let's try to put this in perspective. A binary search is O(log N). A linear search is O(N). In sorting, the "slow" algorithms are O(N2), and the "advanced" algorithms O(N lg N). A factorial-complexity is (obviously enough) O(N!).
Let's try to put some numbers to that, considering (for the moment) only 10 items. Each of these will be roughly how many times longer processing should take for 10 items instead of 1 item:
O(log N): 2
O(N):10
O(N log N): 23
O(N2): 100
O(N!): 3,628,800
For the moment I've cheated a bit, and use a natural logarithm instead of a base 2 logarithm, but we're only trying for ballpark estimates here (and the difference is a fairly small constant factor in any case).
As you can see, the growth rate for the factorial-complexity algorithm is much faster than for any of the others. If we extend it to 20 items, the difference becomes even more dramatic:
O(log N): 3
O(n): 20
O(N log N): 60
O(N2): 400
O(N!): 2,432,902,008,176,640,000
The growth rate for N! is so fast that they're pretty much guaranteed to be impractical except when the number of items involves is known to be quite small. For grins, let's assume that the basic operations for the processes above can each run in a single machine clock cycle. Just for the sake of argument (and to keep the calculations simple) let's assume a 10 GHz CPU. So, the base is that processing one item takes .1 ns. In that case, with 20 items:
O(log N) = .3 ns
O(N) = 2 ns
O(N log N) = 6 ns
O(N2) = 40 ns
O(N!) = 7.7 years.