bunchr (version 1.2.0)

notch_estimator: Analyzing Bunching at a Notch

Description

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.

Usage

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")

Arguments

earnings

Vector of earnings, hopefully a very large one

zstar

Place of kink (critical earning point)

t1

Tax rate before kink

t2

Tax rate after kink

Tax

"Penalty" tax for crossing zstar.

cf_start

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

cf_end

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

exclude_before

Number of excluded bins before the kink bin.

exclude_after

Number of excluded bins after the kink bin.

force_after

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.

binw

Bin width.

poly_size

Order of polynomial used to calculate counter-factual histogram.

convergence

Minimal rate of change of bunching estimate to stop iterations.

max_iter

Maximum number of iterations for bunching estimates.

select

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

draw

Should a graph be drawn?

title

Title for plot output

varname

Name for running variable, to be desplayed in the plot

Value

notch_estimator returns a list of the following variables:

Details

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.

References

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

See Also

bunch, kink_estimator

Examples

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