I really really hate dynamic programming
I have a bit up on Crooked Timber at the moment, attempting to make a model of when Tony Blair gets forced out of power. It’s a tricky little thing which I ended up solving in an Excel spreadsheet using my patented I Can’t Believe It’s Not Dynamic Programming technique (email me if you want the spreadsheet, though I can’t fathom why you would). Trying to do it properly reminded me why I hate dynamic programming with such a passion and think it really ought to be removed from the economics syllabus, even at the cost of rewriting a huge amount of economics which uses it.
1. It’s bloody difficult. There are loads of interesting mathematical tools which are never covered on economics courses because people have to go through all the calculus you need in order to be able to do dynamic programming. If it was dropped, you could have stochastic calculus on the main economics syllabus, you could do much more probability theory and actuarial maths, you could cover Bayesian econometrics in a sensible manner and so on. We could even, god help us, have a proper go at the sort of stuff Barkley Rosser covers in his rather expensive book.
2. It encourages you to work in “economist’s time”, which is to say, no time at all. Dynamic programming works on problems that have a well-defined beginning and a well-defined end (or a hazy “infinite horizon” that does the work of a well-defined end). Economic problems of any substance are much more likely to have started way back in the mists of time and to drag on to an unspecified future date (note that an “indefinite” future is very certainly not the same thing as an “infinite” one, and I intend to write about this subject one of these days). Flattening down proper, historical time into the sort of uninteresting timeless time of a programming model is just dealing with the dynamics of a situation by ignoring them; I think it was Steve Keen who noted that a dynamic programming model is really just a one-period model being tricked into doing some of the work of a proper dynamic model.
3. It encourages you to make assumptions about important functions because of the way they fit into dynamic programming models rather than because of any real thought about the underlying mechanism. See my CT piece for an example; I modelled the “grovelling function” as a hazard rate because I knew it would be easier to do the maths that way; as it happens I think I can make a decent case why I think that grovelling is a hazard-rate type of process but that’s not really why I did it. An even more degenerate case of this is can be seen in the countless thousands of papers in the literature where someone has found a dynamic programming solution to some problem or other under a Markov assumption. There are actually very few economic processes which aren’t history-dependent, but it is one hell of a lot easier to do the maths if you make this assumption (in fact, if you don’t, it isn’t really dynamic programming).
4. Related to 2 and 3 above, dynamic programming solutions tend to get you into the habit of treating time as a factor of production or consumption; you allocate X days to A and Y days to B and it doesn’t really matter in the model which days you allocate. This is a bad way of thinking about time and uncertainty. Every year or so, somebody says that we in economics ought to start thinking seriously about “Knightian uncertainty”, but it is more or less impossible to do that in a dynamic programming framework; any assumptions which deliver the boundedness and time-separability that you need, are going to radically limit the space of what outcomes are possible, no matter how clever your stochastic modelling is.
More to come in this vein �