notch_estimator {bunchr}R Documentation

Analyzing Bunching at a Notch


Given a kinked budget set, this function gets a vector of earnings and analyzes bunching. This function could be run independently, but best used through the bunch function.


notch_estimator(earnings, zstar, t1, t2, Tax = 0, cf_start = NA,
  cf_end = NA, exclude_before = NA, exclude_after = NA,
  force_after = FALSE, binw = 10, poly_size = 7, convergence = 0.01,
  max_iter = 100, select = TRUE, draw = TRUE,
  title = "Bunching Visualization", varname = "Earnings")



Vector of earnings, hopefully a very large one


Place of kink (critical earning point)


Tax rate before kink


Tax rate after kink


"Penalty" tax for crossing zstar.


Number of bins before the kink bin where counter-factual histogram should start.


Number of bins after the kink bin where counter-factual histogram should start.


Number of excluded bins before the kink bin.


Number of excluded bins after the kink bin.


Should bunch be forced to use of the provided exclude_after for the end of the bunching, rather than trying to find the bin where the sum of the integral is zero? See details.


Bin width.


Order of polynomial used to calculate counter-factual histogram.


Minimal rate of change of bunching estimate to stop iterations.


Maximum number of iterations for bunching estimates.


Should model selection be used to find counter-factual histogram? See details.


Should a graph be drawn?


Title for plot output


Name for running variable, to be desplayed in the plot


A histogram is created from the earnings vector, with the kink point zstar as the center of one of the bins.

For "unpure" notches, where the marginal tax rate after the notch is different than the one before it, this function disregards the shifting of post-notch distribution to the right, as suggested by Kleven (2016). Asssumption is that the notch effect is much stronger anyway.

Model selection works using the step function from the stats package. It runs backwards from the full polynomial model, trying to find the best explanatory model using the Akaike Information Criterion.

By default, notch_estimator will try to find the end of the notch, i.e. a histogram bin defining a right-side boundary for a range of an excluded area. An interpolation of the counts inside this range renders an equality between the sum of the “excess” counts, from the left side to the notch point, and the sum of “missing” counts from the notch point to the notch size. notch_estimator goes through an iterative process to find a stable right-side boundary, labels it notch_size and returns it. However, the user might want to force a visibly detectible end of notch, rather than let notch_estimator calculate one. Use this option with caution: the notch size is then used to calculate elasticity. For calculating intensive margin elasticities, excess bunching must all come from other bins. Thus, total sums must be equal and forcing the notch size might not be appropriate. In other settings, e.g. a labor market with extensive margins (entry and exit from labor force), forcing the notch size might be helpful.


notch_estimator returns a list of the following variables:


Estimated elasticity


The sum of total estimated extra bunching in the area starting at cf_start and through the notch bin (zstar)


Distance between notch bin and bin where the estimated influence of the notch ends, delta_zed


A data frame with bin mids, counts, counter-factual counts, and excluded dummy


Kleven, H J (2016). Bunching, Annual Review of Economics, 8(1).

See Also

bunch, kink_estimator


ability_vec <- 4000 * rbeta(100000, 2, 5)
earning_vec <- sapply(ability_vec, earning_fun, 0.2, 0.2, 0.2, 500, 1000)
bunch_viewer(earning_vec, 1000, 15, 30, 2, 21, binw = 50)
notch_estimator(earning_vec, 1000, 0.2, 0.2, 500, 15, 30, 2, 21, binw = 50,
draw = FALSE)$e

[Package bunchr version 1.2.0 Index]