In rock climbing, it's common to protect climbs with spring-loaded camming
devices (or just "cams" for short). You insert a cam into a handy crack in the
rock, clip your rope to it and then climb past; if you fall, then the downward
force on the cam will cause it to bite harder into the rock and arrest your
fall. Modern cams can literally hold the weight of a car:

http://www.dmmclimbing.com/video.asp?id=2

Cams revolutionised rock climbing when they were invented in the 70s: suddenly,
loads of routes were merely scary instead of unprotectable death routes. But
there are two problems with cams: they're expensive and heavy. Well, make that
three problems: each cam can only grip cracks whose width is within a given
range, so your "rack" needs to contain cams of the correct sizes for your
route. Here's an investigation of current cams on the market, and a calculation
of their weight-efficiency.

http://www.summitpost.org/size-matters-a-gear-comparison/694359

But, I thought, this sounds like a linear programming problem. We just need to
ask a user what range of cracks they're likely to want to protect (to a first
approximation, this is a feature of the crag and rock type you're climbing on),
and then we can use MATHS!!!!11!!7!! to calculate the minimum-weight set of
cams that covers that range. Treat each 1mm range as a binary coefficient (we
need to protect 203-204mm cracks/we don't need to), treat each type of cam as a
variable, have "sum of weights" as our objective function, and throw
Algorithm::Simplex at it. Even better, we could use "sum of costs" as our
objective function to get the cheapest possible rack, or a linear combination
of the two (obtained by asking the user "how much would you pay to shave 10g
off your rack?") and get a personalised "best rack for you" calculation.

Then I realised that Algorithm::Simplex would probably tell me to buy 2/7 of a
Black Diamond #4 and 1/3 of a DMM #3, and that this would be precisely no use
to me. So I googled for "integer programming", and discovered that this was
NP-hard :-(

But did this dishearten me? No, of course not! Currently (thanks to Murray
Walker) I'm trying a dynamic programming/divide-and-conquer approach. Other
possibilities include:

 * Genetic algorithms
 * Metropolis-Hastings/simulated annealing
 * Brute-force search with aggressive pruning of the search tree
 * Shell out to external integer-programming tools
 * Write my own branch-and-cut implementation.