## Partition Numbers

### April 15, 2011

The partition-number function *P*(*n*) gives the number of ways of writing *n* as the sum of positive integers, irrespective of the order of the addends. For instance *P*(4) = 5, since 4 = 4 = 3 + 1 = 2 + 2 = 2 + 1 + 1 = 1 + 1 + 1 + 1. Sloane’s A000041 gives the first ten partition numbers as 1, 2, 3, 5, 7, 11, 15, 22, 30, and 42; the numerous references to that sequence point to many fascinating facts about partition numbers, including their close association with pentagonal numbers. By convention, *P*(0) = 1 and *P*(*n*) = 0 for negative *n*. Partition numbers are normally calculated by the formula, which was discovered by Leonhard Euler:

Your task is to write a function that computes *P*(*n*), and to calculate *P*(1000). When you are finished, you are welcome to read or run a suggested solution, or to post your own solution or discuss the exercise in the comments below.

Pages: 1 2

My Haskell solution (see http://bonsaicode.wordpress.com/2011/04/15/programming-praxis-partition-numbers/ for a version with comments):

[...] today’s Programming Praxis exercise, our goal is to write a function to calculate partition numbers and to [...]

A Python solution:

My non-recursive solution in Python:

My Python solution, similar to Dave Webb’s:

A version that runs faster on my laptop, based on a formula given on the Mathworld page:

Here’s a ruby version. The PN array is used for caching. I actually tried using inject, but couldn’t get the caching working with it. I’d love to see someone else’s version with that in there.

Also @Dave’s python version memoizing the function is pretty cool. I haven’t tried anything like that in Ruby. Anyone know if it’s doable?

Here’s my Ruby implementation:

$partitions = [1,1,2,3,5,7,11,15,22,30,42]

def partition(n)

return 0 if n < 0

return $partitions[n] if $partitions[n] != nil

partition = 0

1.upto(n) do |k|

partition += (-1) ** (k + 1) * (partition(n – (k * (3 * k – 1)) / 2) + partition(n – (k * (3 * k + 1)) / 2))

end

$partitions[n] = partition

return $partitions[n]

end

p partition(1000)

Here’s the output:

24061467864032622473692149727991

I was inspired by @Remco’s slick Haskell solutions to try my own. After little

luck with IntMaps (perhaps due to overflow?) I came up with the following. Note:

I’m indebted to @Remco for nearly all of this, either in this exercise or

previous ones.

inspired by you graham

Straight Scheme with delayed and forced promises.

(The promise at 0 remains an empty sum. The rest are good.)

Hey there! New to the site, but already loving it. Here’s my Python solution. Much like the above, with one VERY BIG time saving feature. (I’m not sure if the “regular crowd” here is in to optimizations… but this one seemed worthy of note.)

@memoize

def partition_number_opt1(n):

if n < 0: return 0

if n == 0: return 1

sum = 0

for k in range(1,n+1):

# slight optimization:

# once the inner expressions get below zero, then all remaining

# partition numbers (in the rest of the sum) are zero,

# thus they contribute nothing to the sum.

# so: break out of the loop

if n-(k*(3*k-1)//2) < 0: break

sum += ((-1) ** (k+1)) * (partition_number_opt1(n-(k*(3*k-1)//2))+partition_number_opt1(n-(k*(3*k+1)//2)))

return sum

Just trying my post once again, after I “read the manual”. Mea culpa!

Using Dan’s observation as an excuse for a little refactoring that I wished

I did in the first place: making sum a procedure of its own. And yes, it

does feel faster with the early completion of the sums.

The recursive solution is very slow because redundant calculation of partition numbers.

So, The trick is to remember the previously calculated value of partition numbers.

Checkout my implementation in C using red-black trees.

http://codepad.org/vKEivBGq

Here is my non-recursive python solution, simple and efficient!

Since Euler’s formula is complex for calculation, I used another algorithm,

instead, which can easily be discovered from the process of partition.

I found this quite interesting, as there is an enormous range of performance between different solutions. The Perl version below is combinatorial and, at least for me, is quite a bit faster and less memory than the previously shown ones (barring the C double solution which isn’t correct for large values). However it is about 300 times slower than the GMP combinatorial solution below. In turn, that is about 1,000 times slower than the Rademacher formula used in Pari or SymPy. Pari in turn is quite a bit slower than Jonathan Bober’s MPFR Rademacher solution. The current state of the art implementation seems to be Fredrik Johansson’s FLINT/MPFR/Arb implementation which looks to be over 1000x faster than Pari, computing p(10^12) in under 12s. The growth rates differ (especially between the combinatorial and Rademacher solutions), so the “x faster” is simplistic.

In Perl, computes p(10000) in about 8s.

In C+GMP, computes p(200000) in about 5s. Compile with “gcc -O partitions.c -lgmp -lm”.