n n! 0 1 1 1 2 2 3 6 4 24 5 120 6 720 7 5040 8 40320 9 362880 10 3628800 11 39916800 12 479001600 13 6227020800 14 87178291200 15 1307674368000 16 20922789888000 17 355687428096000 18 6402373705728000 19 121645100408832000 20 2432902008176640000 25 1.5511210043E25 42 1.4050061178E51 50 3.0414093202E64 70 1.1978571670E100 100 9.3326215444E157 450 1.7333687331E1,000 1000 4.0238726008E2,567 3249 6.4123376883E10,000(Source: Wiki[^]

And if you look at long - 4 bytes as you say - that's not a 64 bit number. 4 bytes is 4 * 8 == 32 bits, so the largest number it can store is 2,147,483,647...so your method "runs out of steam" at 12! and wraps back to a "random" number.

[edit]Wiki Table truncated and cleaned - OriginalGriff[/edit]

**"thank you but why when I input bigger numbers than 12 I get wrong results??"**

This all has to do with how computers store numbers. Lets just work with a smaller number of bits (or I have to lean on the "0" key for far too long( and assume that an int contaiuns just four bits.

Obviously, the largest number it can store is when each bit is '1' right? 1111b (or 0xF or 15 in decimal).

Wrong. If we did that, we would have nowhere to store negative numbers, because the "positiveness" or "negativeness" of a number needs a bit to store it.

Conventionally, computers use the highest, or left most bit to indicate negative numbers: any value with the "top bit" set is negative, and with it clear (or '0') the value is positive.

So the largest value we can store is 0111b (or 7 in hex and decimal) - the values range

0111b 7 0110b 6 0101b 5 0100b 4 0011b 3 0010b 2 0001b 1 0000b 0 1111b -1 1110b -2 1101b -3 1100b -4 1011b -5 1010b -6 1001b -7 1000b -8 or "negative zero" depending on the system.So, when you add 2+3, your get 5:

0010b 2 +0011b 3 =0101b 5But what happens when you add 5 + 6?

0101b 5 +0110b 6 =1011b -5Arrggh! Noooooooo! But that is what happens - the "extra" bit from the addition of 0101b and 0110b moves into the "top bit" so the number becomes negative. If you continue to add to this then you will "overflow" the "top bit" as well, and at that point the result start to become very unpredictable and will vary depending on the system you run on, the compiler you use, the compilation switches you set and a host of other (mostly rather dull) effects.

And don't forget, multiplication is (at it's most basic) just a lot of adding up! :laugh:

When you scale this up to 32 bits, you get the same problems the moment you try to exceed 2,147,483,647 in an integer: because it's value is

0111111111111111111111111111111111111111111111111111111111111111 in binary. Add one, and it goes negative and your problems begin...:laugh: