factorial(100)

[Neal Becker]

Total newb here, just playing around. A bit surprised by this:

julia> factorial(100)
0

[John Myles White]

http://www.johnmyleswhite.com/notebook/2013/01/03/computers-are-machines/

 -- John

[Stefan Karpinski]

Great post, John. Didn't know you'd written that.

[John Myles White]

Thanks. This question was becoming a FAQ, so it seemed time to have a compiled answer.

 -- John

[Stefan Karpinski]

Well done. I've added some feedback / my 2¢ / fed the flames with a couple of comments.

[Alessandro "Jake" Andrioni]

The great post by John post already explains it, but the answer in
this case would be to use `factorial(BigInt(100))`.

Most functions should work without an issue using BigInt, but there
are faster implementations of some of them from GMP exposed in the
package Catalan.

Stefan, one point: in your comment, you wrote:
> In this case, if you understand that Julia’s integers are machine Int64s, then you understand exactly how they behave how they are represented.

but it's also important knowing that the integer size in Julia depends
on the architecture, while the float size doesn't, I had some issues
using Julia on Windows because of this.

[Pedro Rafael]

Use factorial(BigInt(1000))

[   ],
Pedro Rafael Diniz Marinho.

2013/2/27 Alessandro "Jake" Andrioni <jake...@gmail.com>

[Pedro Rafael]

Notes that the outcome of the code below is true.

factorial(BigInt(21))>=typemax(Int64)

Thus, 64 bits can not represent the number 51090942171709440000. Working with numbers greater than the maximum representation of integers makes the code slower. However, it is often necessary. Thus, use BigInt.

[   ],
Pedro Rafael Diniz Marinho.

2013/2/27 Pedro Rafael <pedro.rafa...@gmail.com>

[Stefan Karpinski]

On Wed, Feb 27, 2013 at 8:05 PM, Alessandro "Jake" Andrioni <jake...@gmail.com> wrote:

Stefan, one point: in your comment, you wrote:
> In this case, if you understand that Julia’s integers are machine Int64s, then you understand exactly how they behave how they are represented.

but it's also important knowing that the integer size in Julia depends
on the architecture, while the float size doesn't, I had some issues
using Julia on Windows because of this.

Yes, this is another one of those things done for efficiency and effectiveness. We considered using 64-bit integers everywhere, but the thing is they're just horribly inefficient on 32-bit systems. And you can't address that much memory on a 32-bit system anyway. So what you really want is to default to having 32-bit integers everywhere on those systems. It's a complication, but it's kind of necessary to avoid screwing up the performance on small word machines. 

[Vincent Grunert]

It's not a pretty solution but it works:

use:

#code
gamma(n+1)

instead of:

#code
factorial(n)

https://en.wikipedia.org/wiki/Gamma_function

[Yichao Yu]

On Tue, Sep 1, 2015 at 9:34 AM, Vincent Grunert <vgru...@gmail.com> wrote:
> https://en.wikipedia.org/wiki/Gamma_function
>
> Just to be on the save side.
>
>
> On Tuesday, September 1, 2015 at 3:32:17 PM UTC+2, Vincent Grunert wrote:
>>
>> Just found this:

>>
>> use:
>>
>> #code
>> gamma(n+1)
>>
>> instead of:
>>
>> #code
>> factorial(n)
>>

>> it's not pretty but nicer then the bigint solutions I believe.
>>

This really depend on what you need. If you need all the digits,
there's no way around using BigInt. If you are doing some floating
point calculation, you can use gamma, although in practice I often
find lgamma is what I really need. (Since factorial often appears in
some expansion coefficient with pretty big numerator and denominator.
Using the log version can avoid floating point overflow)

>>
>>
>> On Wednesday, February 27, 2013 at 10:58:34 PM UTC+1, nbecker wrote:
>>>

[Steven G. Johnson]

On Tuesday, September 1, 2015 at 9:39:27 AM UTC-4, Yichao Yu wrote:

find lgamma is what I really need. (Since factorial often appears in
some expansion coefficient with pretty big numerator and denominator.
Using the log version can avoid floating point overflow)

If you are doing expansions, e.g. some series formula, it is usually best to compute the series coefficients by a recurrence (e.g. compute the next coefficient as the previous coefficient multiplied by some factor), which is vastly more efficient than calling things like gamma or lgamma for each term, and typically this avoids overflow as well.

[Cedric St-Jean]

On Thursday, September 3, 2015 at 10:01:00 PM UTC-4, Steven G. Johnson wrote:

If you are doing expansions, e.g. some series formula, it is usually best to compute the series coefficients by a recurrence

Why? I can see how it can be more efficient, but wouldn't the inaccuracies compound?

[Steven G. Johnson]

Not nearly quickly enough to matter in typical calculations.  (For e.g. computation of special functions, it's rare to evaluate series expansions to more than tens of terms.  If you are evaluating series with thousands of terms or more, it is probably something like a Chebyshev expansion where you should be using specialized methods anyway.)

The classic example of computing series terms by a recurrence is the well-known Horner's method.