people misunderstanding the problem (which is not surprising; it's the sort of problem mathematicians are better at understanding than the general population, and the audience there is not necessarily mathematicians);

programmer types whining "waah, this problem is in NP, I can't do it!". Is it in NP? I don't feel like thinking about that -- but I did it in a few minutes, and more importantly with a couple seconds of computation time. NP doesn't stand for "not possible";

people saying "who cares, most of those combinations are politically unrealistic!" (which I have to admit is true);

a few estimates of the answer based on some quick and dirty statistical assumptions, which look basically right;

and a couple people (me included) who have gotten a numerical answer.

I'd explain my solution here, but I think some of you might want to try out this problem. If you poke around in the comments at FiveThirtyEight.com you can find my solution.

What's interesting to see is that a lot of people seem to believe you have to actually generate the sets in order to count them. That would of course be hopeless. The explanation of combinatorics as "counting without counting" comes to mind.

I was surprised how close the quick and dirty statistical solution came to the exact answer.

As ray points out, this is related to knap sack problem. (The knap sack problem would ask for the smallest number of delegates possible above 270...)Coincidently, given todays computation power, we can solve a knap sack problem with 50 problems exhaustively.

I don't think this problem is NP hard. Actually finding all the combinations would be, but that wasn't what was asked. It can be solved in approximately n^2 time, using essentially the same method Isabel used, writing out an algorithm that is probably very similar to what matlab uses to solve equations.

I tried it, on your advice. My weapon of choice is Perl. It wasn't hard, but it was surprisingly tricky to get it exactly right. The program also definitely requires memoization -- not entirely coincidentally a topic that you've discussed before, and somewhat coincidentally a Perl module that Mark-Jason Dominus developed. I'll note that even with your approach you used a software system to automate the tedium.

I'll also note that the number of function calls to "calc()", with Memoization, was only 13307, which surprised and pleased me, not least because the echo of l337. :-)

guessing before reading anything else on this page or those linked: generatingfunctionology? Even if it's not the quickest route, the overhead involved in setting up the problem lends itself to answering related questions, and thus gives a pretty good RoI