Recursion: Introduction

Macroeconomics, empirical and theoretical, is built on dynamic models. These models naturally lead you to recursion as an elegant solution. Most notably, modern graduate-level macro courses start with a discussion of dynamic programming and the Bellman Equation.¹ The titles of some of the heavyweight textbooks in macro indicate the importance of recursion:

• Recursive Macroeconomic Theory (Ljungqvist and Sargent)
• Recursive Models of Dynamic Linear Economies (Hansen and Sargent)
• Recursive Methods in Economic Dynamics (Stokey and Lucas with Prescott)
• Recursive Methods of Computing Equilibria of Business Cycle Models (chapter by Hansen and Prescott)

The Ljungqvist and Sargent textbook starts with “Part I: The imperialism of recursive methods”. As they make clear, it’s not just that recursive methods are a popular approach to solving macro models these days, they are more or less the only way to do so. Over time, I have come to the conclusion that the best way for economists to implement dynamic econometric models on the computer is to use recursion. There are a couple of reasons for this:

• Graduate students in economics understand the concept of a recursive formulation of mathematical problems after taking their core macro courses.
• Most graduate students in economics have a limited scientific programming background, and it’s easier for those new to programming to write out correct solutions to problems when using recursion rather than other methods.

The second claim might seem outrageous to the average working programmer. I’m aware of the arguments against recursion for beginning programmers, but I don’t think they apply to beginning programmers that have completed the core courses in a typical US economics PhD program. The big hurdle with using recursion is to learn to think recursively. Economics graduate students have already gotten over that pain, so that argument simply does not apply.

The beauty of recursion is that it imposes a lot of discipline on the programmer. Handling a dynamic problem with recursion requires most of the programming to take place before the student starts typing. Inexperienced programmers operating without any discipline tend to write programs that are a diary of their learning experiences. What could potentially be handled cleanly and clearly without recursion rarely is. Recursive functions are seldom cluttered, independent of the experience level of the student. Undisciplined programs can be, and often are, arbitrarily bad. It’s not easy to verify the correctness of 200 lines of spaghetti code.

This version: November 20, 2020