The correlation with my program's results is clear (the coefficients are my last column) - any references as to why?
Multiplying two power series maintains that property -- the x^j term in the product of two power series comes from x^i in one power series and x^(j-i) in the other power series, just like a sum of j pence made out of two types of coins has to be i pence worth of one type of coin and j-i pence worth of the other type of coin.
Converting (1/(1-x)) * (1/(1-x^2)) * ... into 1/((1-x) * (1-x^2) * ...) is just routine algebraic manipulation, which I claim without proof is valid for power series.
That's a fair point. I should revisit my critique: IMO, PE should be used to practice conceptual mathematics; if you're trying to perform an exhaustive search, for example, you might want to see if there's a better way.
Here's a list of async-signal-safe functions (scroll down): http://pubs.opengroup.org/onlinepubs/009695399/functions/xsh...
I know I'm missing the point of the post, but it is a particular nit that I pick. You'd be surprised at how often this happens in production code, and how often it causes mysterious, hard-to-reproduce bugs.
Not exactly pretty, but using signals to trigger to produce reports isn't exactly pretty either.
Unfortunately, signals are often abused in this manner. Not a big deal for such for this small piece of software, but in larger systems this kind of abuse can cause very hard to fix bugs.
If you do, your code is buggy: sig_atomic_t is the only type you can safely use inside and outside a signal handler.
It's an interesting problem. My gut reaction was to solve X1 + X2 + (...) + X6 = 200; X1, ..., X6 < 0, which would be C(205, 200), but that ignores the denominations of each coin, so it doesn't really generate what you want.
coins = [1, 2, 5, 10, 20, 50, 100, 200]
total = 200
matrix =  * (total + 1)
matrix = 1
for coin in coins:
for j in range(coin, len(matrix)):
matrix[j] += matrix[j - coin]
`,` creates a tuple, not parentheses (empty tuple is an exception).