Mathematics Stack Exchange is a question and answer site for people studying math at any level and professionals in related fields. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Bell number B(n) is defined as the number of ways of splitting n into any number of parts, also defined as the sum of previous $n$ Stirling numbers of second kind.

Wikpedia page gives the following python code to print bell polynomials,here is the link which returns the $n^{th}$ Bell number.(this can also be found on the wikipedia page if scrolled down)

but when I use the Dobinski formula , and write the following code(in python),

import math
def bell_number(N):
return (1/math.e) * sum([(k**N)/(math.factorial(k)) for k in range(ITERATIONS)])

I get a different answer

for instance,

$5^{th}$ bell number according to the code provided by wikipedia is $52$ but what the other code returns is $50.767362881659039$

Can you throw some light on this matter, as to why am I getting different answer (possibly incorrect) using Dobinski formula ?

P.S. Is this question inappropriate for this site, if yes then where else must I ask this?

share|cite|improve this question
You're adding up a lot of very small terms. If you aren't using arbitrary-precision arithmetic they'll evaluate to zero sooner or later. – Qiaochu Yuan May 28 '12 at 15:26
what arbitrary-precision must I use? (and what is arbitrary-precision?) – Tomarinator May 28 '12 at 15:30
So its like the answer i am getting is affected by my computers processing speed. – Tomarinator May 28 '12 at 15:37
It has nothing to do with speed; the issue is memory. By default, a programming language typically assigns a fixed amount of memory to represent a given number. If you try to represent a number with more precision than that, the computer will just ignore whatever doesn't fit into the digits it represents (if it's too small) or return an error (if it's too big). Ask Python to print out the individual terms in your series rather than their sum to see what I mean. – Qiaochu Yuan May 28 '12 at 15:48
up vote 4 down vote accepted

The problem is that Python is taking the floor of the terms in the sum. I'm not a Python expert, but I think you need to tell Python somehow to use floats rather than integers in the sum.

Addendum: To follow up on the discussion in the comments, this modified version of your code should work:

def fact(n):
    while n > 0:
        r = r * n
        n = n - 1

import math
def bell_number(N):
    return (1/math.e) * sum([(float(k)**N)/fact(k) for k in range(ITERATIONS)])

For small $N$, ITERATIONS = 1000 is unnecessary. You can truncate the sum once the percentage change due to the most recent term drops below the threshold of machine precision. Moreover, it is machine precision, rather than the need to truncate the sum, that will be the limiting factor in obtaining exact integer values beyond about $N=20$, unless you go to multiple- or arbitrary-precision arithmetic.

share|cite|improve this answer
If it took floored values , then why would it return a decimal answer? – Tomarinator May 28 '12 at 16:07
When you divide by e, the number gets converted to decimal. It's integer up to that point. – Will Orrick May 28 '12 at 16:09
Try this: 1/(math.e) * sum([float(k)**5/fact(k) for k in range(30)]) – Will Orrick May 28 '12 at 16:11
O.ops ,so thats how it is – Tomarinator May 28 '12 at 16:11
I tried it your way, but it the compiler returns an error "OverflowError: long int too large to convert to float" – Tomarinator May 28 '12 at 16:17

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.