1. ## Factorial

I am trying to figure out what is the largest number that i can evaluate a factorial using an int, long, float etc...

I already figured out how to find the value for the factorial but how do I test to see when it overloads so I know what the largest number is???

2. A crude way of doing it is to keep going until the result is less than what you got before. When I tried it on a 32-bit signed integer, I got that:
Code:
```i= 1 i!= 1
i= 2 i!= 2
i= 3 i!= 6
i= 4 i!= 24
i= 5 i!= 120
i= 6 i!= 720
i= 7 i!= 5040
i= 8 i!= 40320
i= 9 i!= 362880
i= 10 i!= 3628800
i= 11 i!= 39916800
i= 12 i!= 479001600
i= 13 i!= 1932053504
i= 14 i!= 1278945280
i= 15 i!= 2004310016
i= 16 i!= 2004189184
i= 17 i!= -288522240```
Now you might think that the train went off the rails with 17! because it's negative. But actually the problem is with 14!, for it is less than 13!.

3. If a and b are both positive int values, then
Code:
`if  (a > std::numeric_limits<int>::max()/b) multiplying_a_and_b_would_overflow();`

4. Originally Posted by grumpy
If a and b are both positive int values, then
Code:
`if  (a > std::numeric_limits<int>::max()/b) multiplying_a_and_b_would_overflow();`
Actually do that. That's a much better solution then mine, because actually, if you got numbers big enough, you could overflow several times over and still have (n+1)! < n!

Actually do that. That's a much better solution then mine, because actually, if you got numbers big enough, you could overflow several times over and still have (n+1)! < n!
Overflowing once is enough to cause problems. The result of signed integer overflow is undefined behaviour. Once undefined behaviour occurs - even once - program behaviour is unpredictable. It is therefore not possible to reliably detect signed integer overflow after the fact.

The purpose of the approach I suggested (there are others) is to detect the potential for overflow before doing the multiplication.

6. Originally Posted by grumpy
Overflowing once is enough to cause problems. The result of signed integer overflow is undefined behaviour. Once undefined behaviour occurs - even once - program behaviour is unpredictable. It is therefore not possible to reliably detect signed integer overflow after the fact.

The purpose of the approach I suggested (there are others) is to detect the potential for overflow before doing the multiplication.
Surely true, which is why I liked your approach.

7. thanks but I'm a little lost on what that code would do...

8. Hint:

If a > c / b, a *b > c.