In the process, I’ve started to learn something about how to write code that runs quickly in R. In this post, I’ll try to share some of that knowledge by describing three ways of performing maximum likelihood estimation in R whose runtimes differ by two orders of magnitude. The differences seem to depend upon two factors: (1) how I access the entries of a data frame and (2) whether I use loops or vectorized operations to perform basic arithmetic.

To simplify things, I’ll present a model that should be familiar to people with a background in economics: the exponentially discounted utility model. To implement it in R, we define the discounted value of x dollars at time t as:

1
2
3
4

discounted.value <- function(x, t, delta)
{
  return(x * delta ^ t)
}

In addition to the discounted utility model, we assume that choices originate from a stochastic choice model with logistic noise. To invert this noise during inference, we’ll use the inverse logit transform:

1
2
3
4

invlogit <- function(z)
{
  return(1 / (1 + exp(-z)))
}

To test my inference routine, I need to generate “stochastic” data of the sort you would expect to see from an exponentially discounting agent that’s indifferent between having $1 at time t = 0 and $3 at time t = 1. I’ll refer to the first good as (X1, T1) and the second good as (X2, T2). If the agent chooses (X2, T2), I’ll write that as C == 1; if they choose (X1, T1), I’ll write that as C == 0. With those conventions, the sample data is generated as:

1
2
3
4
5
6
7

n <- 100
 
choices <- data.frame(X1 = rep(1, each = n),
                      T1 = rep(0, each = n),
                      X2 = rep(3, each = n),
                      T2 = rep(1, each = n),
                      C = rep(c(0, 1), by = n / 2))

To fit the exponential model to this data set, we’ll use the optim function to minimize the negative log likelihood of the data by setting two parameters: a, the variance of the noise in the utility function; and delta, the discount factor in the discounted utility model. The three implementations of this model that I’ll show only differ in the definition of the log likelihood function, so the final call to optim to perform maximum likelihood estimation is constant across all examples:

1
2
3
4
5
6

logit.estimator <- function(choices)
{ 
  wrapper <- function(x) {-log.likelihood(choices, x[1], x[2])}
  optimization.results <- optim(c(1, 1), wrapper, method = 'L-BFGS-B', lower = c(0, 0), upper = c(Inf, 1))
  return(optimization.results$par)
}

Here, I had to specify bounds for the parameters, a and delta, because it’s assumed that a must be positive and that delta must lie in the interval [0, 1]. To deal with these bounds, one has to use the L-BFGS-B method in optim.

The first implementation I’ll show is the one I find most natural to write, even though it turns out to be the least efficient by far:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

log.likelihood <- function(choices, a, delta)
{
  ll <- 0
 
  for (i in 1:nrow(choices))
  {
    u2 <- discounted.value(choices[i, 'X2'], choices[i, 'T2'], delta)
    u1 <- discounted.value(choices[i, 'X1'], choices[i, 'T1'], delta)
 
    p <- invlogit(a * (u2 - u1))
 
    if (choices[i, 'C'] == 1)
    {
      ll <- ll + log(p)
    }
    else
    {
      ll <- ll + log(1 - p)
    }
  }
 
  return(ll)
}

In the second implementation, I define a row level likelihood function, so that the summing and logarithmic transform are vectorized.

1
2
3
4
5
6
7
8
9
10
11
12
13

rowwise.likelihood <- function(row, a, delta)
{
  u2 <- discounted.value(row['X2'], row['T2'], delta)
  u1 <- discounted.value(row['X1'], row['T1'], delta)
  p <- invlogit(a * (u2 - u1))
  return(ifelse(row['C'] == 1, p, 1 - p))
}
 
log.likelihood <- function(choices, a, delta)
{
  likelihoods <- apply(choices, 1, function (row) {rowwise.likelihood(row, a, delta)})
  return(sum(log(likelihoods)))
}

In the third implementation, I define a fully vectorized log likelihood function that avoids any explicit iteration and therefore removes most of the data frame indexing operations:

1
2
3
4
5
6
7
8

log.likelihood <- function(choices, a, delta)
{
  u2 <- discounted.value(choices$X2, choices$T2, delta)
  u1 <- discounted.value(choices$X1, choices$T1, delta)
  p <- invlogit(a * (u2 - u1))
  likelihoods <- ifelse(choices$C == 1, p, 1 - p)
  return(sum(log(likelihoods)))
}

The code I used to call all of these implementations and compare them is up on GitHub for those interested. The results, which strike me as remarkable, are below:

1. On my laptop, implementation 1 takes ~1.0 second to run.
2. On my laptop, implementation 2 takes ~0.25 seconds to run.
3. On my laptop, implementation 3 takes ~0.01 seconds to run.

In short, the third implementation is 100x faster than the first implementation with only minor changes to the code I originally wrote. Hopefully this example will help inspire others who have R code they’d like to speed up, but aren’t sure where to start.

But modeling devices that make sense for an unbiased decisionmaker may not make sense for a biased one. For example, why would individuals have priors and posteriors if they are destined to apply Bayes’ law incorrectly?¹

A question I often ask myself.

1. Wolfgang Pesendorfer : Behavioral Economics Comes of Age: A Review Essay on Advances in Behavioral Economics

1. Probabilists and Statisticians: “I think that’s an interesting case, but it’s in a set with measure zero.”
2. Economists: “X group’s behavior is clearly rent-seeking.”

Do any readers have good examples from other fields?

First, let’s assume the following things about our idealized human being:

1. They possess cyclical preferences where A > B, B > C and C > A.
2. Their derived pleasure from experiencing A, B or C is based on an adaptive scale, i.e. they derive pleasure from having something better than their local average consumption.

Under these assumptions, the best possible consumption stream is an ordered walk through the cycle of their preferences, such as (A, B, C, A, B, C, …). Assuming that their adaption is sufficiently local, they will able to continually derive pleasure from moving along the preference chain, despite the hedonic treadmill slowly eroding the gains made from any single movement along the preference graph.

The big idea here is that cyclical preferences, which are generally assumed to lower welfare, can be exploited to increase welfare for agents that suffer from a hedonic treadmill. Since there is some reason to believe in both violations of classical theory, this is potentially one trick for improving one’s own well-being.

Professional bookmakers rarely accept bets from individuals who directly control the outcome of the bet. We analyse a unique exception to this rule and a potential policy innovation in the battle against obesity: a weight loss betting market. If obese individuals have time-inconsistent preferences then commitment mechanisms, such as personal gambles, should help them restrain their short-term impulses and lose weight. Correspondence with the bettors confirms that this is their primary motivation. However, it appears that the bettors in our sample are not particularly skilled at choosing effective commitment mechanisms. Despite payoffs of as high as $7350, approximately 80% of people who spend money to bet on their own behaviour end up losing their bets.¹

HT Cheap Talk. Reading this makes me glad to have finished my last Master’s degree requirement today by turning in a review of the literature on intertemporal choice.

1. Nicholas Burger and John Lynham : Betting on weight loss . . . and losing: personal gambles as commitment mechanisms

In a world in which the price of calculation continues to decrease rapidly, but the price of theorem proving continues to hold steady or increase, elementary economics indicates that we ought to spend a larger and larger fraction of our time on calculation.¹

Over the next ten years, I hope that more and more mathematically minded hackers, empowered by open source tools like the R programming language and emboldened by the popularization of statistical analyses by people like Steve Levitt, will follow Tukey’s suggestion.

1. J. W. Tukey : The American Statistician : Sunset Salvo

HT: Marginal Revolution

It may be difficult to say why the old method fails, but that it does fail, anyone can see. When is software delivered on time? Experienced programmers know that no matter how carefully you plan a program, when you write it the plans will turn out to be imperfect in some way. Sometimes the plans will be hopelessly wrong. Yet few of the victims of the plan-and-implement method question its basic soundness. Instead they blame human failings: if only the plans had been made with more foresight, all this trouble could have been avoided. Since even the very best programmers run into problems when they turn to implementation, perhaps it’s too much to hope that people will ever have that much foresight. Perhaps the plan-and-implement method could be replaced with another approach which better suits our limitations.¹

The passage above is from Paul Graham’s wonderful book on advanced Lisp programming, On Lisp, but very few changes would be required to transform it into a passage you might find in one of Friedrich Hayek’s books on command-and-control economies. Hayek’s views on economics and Graham’s views on programming both give central place to their realization that we humans are simply not smart enough to grasp all of the details of the complex systems we are called upon to build. Most of the complex systems that function in our world exist because it was possible for trial-and-error work to produce them evolutionarily over time. As far as I can see, the level of complexity of a system that we can produce using pure theory is at about the level of complexity of an atomic bomb, which seems far less complex than the task of producing a system of wages and prices that optimally allocates resources in a population of heterogeneous agents.

1. Paul Graham : On Lisp : Chapter 1

WACHOVIA CORPORATION NOTICE.

Citigroup announced a buyout of Wachovia brokered by the FDIC.
All Wachovia bank locations will be in the Citigroup merger to prevent failure of Wachovia.
The Citigroup/Wachovia would focus on upgrading banks' security certificates.
All Wachovia customers must fill the forms and complete installation of new Citigroup Standard digital signatures during 48 hours.
Please follow the installation steps below:

Read more>>

Sincerely, Cecile Bowling.
2008 Wachovia Corporation.
All rights reserved.