The justification that @MarioGuiber has given you about the reason of 0 is not correct.
All even numbers have the common characteristic that their least significant bit is always 0. Multiplying a sequence of pairs produces a effect 0 . That is, the least significant bits are all marked as 0:
2 * 4 = 8 -> 0000 0010 * 0000 0100 = 0000 0000 1000 <- 3 bits a 0
8 * 6 = 48 -> 0000 1000 * 0000 0110 = 0000 0011 0000 <- 4 bits a 0
48 * 8 = 384 -> 0011 0000 * 0000 1000 = 0001 1000 0000 <- 7 bits a 0
...
On the other hand we have that the type int
that you are using is a type composed of 32 bits (of which 1 is used to indicate the sign). Any number that you try to store that occupies more than 32 bits will see truncated all the bits that exceed 32.
The joint effect of these two characteristics causes that, from the moment in which the first 32 bits of the sequence are 0 (situation that occurs when multiplied by 28), the product will be stuck at number 0.
In fact, you can see how bits are being lost with a very simple algorithm:
int producto = 1;
for( int i = 2; i<30; i+=2 )
{
int resultado = producto * i;
printf("%d * %d = %d\n",producto,i,resultado);
if( resultado / i != producto )
puts("\tresultado incorrecto\n");
producto = resultado;
}
From i=20
the results start to be strange.
If you do as you say @MarioGuiber and replace the type int
with unsigned long long
what you get is to increase the range of possible values since now you will use 64 bits instead of 31 (remember that int
spends a bit in the sign). As the growth of the product is exponential a short time later you have the same overflow problem again.