Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow ETIs to vary across income groups #494

Closed
MattHJensen opened this issue Dec 8, 2015 · 11 comments
Closed

Allow ETIs to vary across income groups #494

MattHJensen opened this issue Dec 8, 2015 · 11 comments

Comments

@MattHJensen
Copy link
Contributor

MattHJensen commented Dec 8, 2015

Our behavioral functions should allow the assumed elasticity of taxable income (ETI) --- that is, the behavioral response parameters _BE_sub and _BE_inc --- to vary across income groups.

This would reflect the evidence from Mertens (2015) and Gruber and Saez (2002) among others.

I would suggest looking to those two papers when thinking about which sets of income cuts should be allowed. It does not seem that the function would need to be flexible to any set of income cuts, at least to begin with.

@feenberg
Copy link
Contributor

feenberg commented Dec 8, 2015

On Mon, 7 Dec 2015, Matt Jensen wrote:

Our behavioral functions should allow the assumed elasticity of taxable income (ETI)
to vary across income groups.

This would reflect the evidence from Mertens (2015) and Gruber and Saez (2002) among
others.

I would suggest looking to those two papers when thinking about which sets of income
cuts should be allowed. It does not seem that the function would need to be flexible
to any set of income cuts, at least to begin with.

Two possibilities spring to mind:

  1. Same breakpoints we use for tables
  2. Same breakpoints used in studies of behavioral elasticities.

dan


Reply to this email directly or view it on
GitHub.[AHvQVcrKgUpFK8-E3R-HQPEJu5YV9PFLks5pNhuTgaJpZM4GwoSk.gif]

@martinholmer
Copy link
Collaborator

martinholmer commented Nov 24, 2017

@MattHJensen said on December 7, 2015, in issue #494:

Our behavioral functions should allow the assumed elasticity of taxable income (ETI) --- that is, the behavioral response parameters _BE_sub and _BE_inc --- to vary across income groups.

This would reflect the evidence from Mertens (2015) and Gruber and Saez (2002) among others.

Two questions:

  1. Can you point to the page(s) in the Gruber and Saez paper that show(s) their estimates of the elasticity parameters by income group.

  2. The link to the Mertens paper is broken. Can you provide a link to that paper?

@martinholmer
Copy link
Collaborator

@martinholmer said on Nov 24, 2017, in issue #494:

Our behavioral functions should allow the assumed elasticity of taxable income (ETI) --- that is, the behavioral response parameters _BE_sub and _BE_inc --- to vary across income groups.

This would reflect the evidence from Mertens (2015) and Gruber and Saez (2002) among others.

Two questions:

  1. Can you point to the page(s) in the Gruber and Saez paper that show(s) their estimates of the elasticity parameters by income group.

  2. The link to the Mertens paper is broken. Can you provide a link to that paper?

Given recent comments in pull request #1858, it would seem that there is possibility that there are no econometric estimates that would permit elasticities "to vary across income groups".

If we can't easily resolve the discussion in #1858, how can we possibly do what is being requested in issue #494?

In other words, if the mtr_cap argument to the Behavior.response method is set as low at 0.7 or 0.5, as Dan suggests, what role does allowing elasticities to vary across income (that is, mtr) groups have?

@MattHJensen

@MattHJensen
Copy link
Contributor Author

Given recent comments in pull request #1858, it would seem that there is possibility that there are no econometric estimates that would permit elasticities "to vary across income groups".

This is not the case.

Can you point to the page(s) in the Gruber and Saez paper that show(s) their estimates of the elasticity parameters by income group.

See table 9 on page 24.

@MattHJensen
Copy link
Contributor Author

The link to the Mertens paper is broken. Can you provide a link to that paper?

https://karelmertenscom.files.wordpress.com/2018/01/mmo_january20181.pdf

@martinholmer
Copy link
Collaborator

martinholmer commented Aug 6, 2018

Issue #494 was opened on December 7, 2015, and the last comment in this issue was made on February 13, 2018, nearly six months ago. Issue #494 requests an enhancement to the Behavior class that would allow different values by income subgroup for the _BE_sub and _BE_inc elasticities.

In the meanwhile, a new flexible quantity_response utility function has been added to Tax-Calculator. This function was added to support @derrickchoe's work on charitable-giving responses to changes in the tax treatment of charitable contributions (see #2037). The new function was added in pull requests #1995, #1997, and #2001. And a cookbook recipe illustrating its use was added in pull request #2002 on May 18, 2018.

The quantity_response function was added mainly because of the difficulties of using a custom-modified Behavior class that was like that envisioned in #494. The quantity_response function has been proven to provide a much more flexible way to meet the #494 request.

Given these developments, it seems as if there is little or no reason to keep issue #494 open.
What do others think about #494? Are there reasons to keep it open?

@MattHJensen @feenberg

@MattHJensen
Copy link
Contributor Author

@martinholmer, the quantity_response function is very nifty. Is it correct to say that, under the current arrangement, tc CLI interface users must descend to the Python API to conduct behavioral analyses with different values by income subgroup for the _BE_sub and _BE_inc elasticities?

@martinholmer
Copy link
Collaborator

@MattHJensen said:

the quantity_response function is very nifty. Is it correct to say that, under the current arrangement, tc CLI interface users must descend to the Python API to conduct behavioral analyses with different values by income subgroup for the _BE_sub and _BE_inc elasticities?

Yes, that is correct.

It seems to me that using subgroup variation in elasticities is very advanced analysis, and that pretty much anybody undertaking that sort of advanced analysis would be writing their own Python scripts that use the taxcalc package.

@MattHJensen
Copy link
Contributor Author

MattHJensen commented Aug 8, 2018

@martinholmer, thanks for confirming that only Python API users can currently conduct behavioral analyses with different elasticity values by income subgroup.

I am content closing this issue for now, but...

I do not entirely agree with the rest of your assessment:

using subgroup variation in elasticities is very advanced analysis, and that pretty much anybody undertaking that sort of advanced analysis would be writing their own Python scripts that use the taxcalc package.

My understanding is that using subgroup variation for elasticities is fairly standard practice. Auten at Treasury Office of Tax Analysis insisted that ETI subgroup variation is necessary when @feenberg and I spoke with him a couple of years ago. My understanding is that JCT also includes subgroup variation in their default analyses. This approach has also been pursued by Choe/Brill and researchers from IUPUI working on charitable contributions. I would have used it in the past if it had been easy / out of the box.

So my inclination is that including subgroup variation should be considered a "default" or "standard" approach rather than "very advanced analysis" when it comes to behavioral analysis.

But I don't know the specific break points that should be used when following that "standard" approach, and I am content closing the issue and then waiting for our tc users to request more specific capabilities if they really want them. We can let those future requests guide future enhancements.

@martinholmer
Copy link
Collaborator

@MattHJensen said:

My understanding is that using subgroup variation for elasticities is fairly standard practice. Auten at Treasury Office of Tax Analysis insisted that ETI subgroup variation is necessary when @feenberg and I spoke with him a couple of years ago. My understanding is that JCT also includes subgroup variation in their default analyses. This approach has also been pursued by Choe/Brill and researchers from IUPUI working on charitable contributions. I would have used it in the past if it had been easy / out of the box.

So my inclination is that including subgroup variation should be considered a "default" or "standard" approach rather than "very advanced analysis" when it comes to behavioral analysis.

Well, I guess its a matter of semantics. Auten at Treasury/OTA and JCT are pretty advanced users in my book.
And Choe/Brill were already doing Python-scripting analysis before we developed the quantity_response function for them.

@MattHJensen continued:

But I don't know the specific break points that should be used when following that "standard" approach ...

That is exactly the problem we face if we try to build into Tax-Calculator anything more structured than the flexible quantity_response function. If you look at the papers you mention earlier in the issue #494 discussion, it is not at all clear how to project to current years the income (whatever concept of income they used) brackets they used. And do you really think Auten and JCT use the same income concept and the same income brackets in their analysis? I agree that Treasury and JCT use subgroup-varying elasticities in their work, but I don't imagine there is any standard way of doing this.

@MattHJensen concluded:
... I am content closing the issue and then waiting for our tc users to request more specific capabilities if they really want them. We can let those future requests guide future enhancements.

This seems like a sensible approach.

@feenberg
Copy link
Contributor

feenberg commented Aug 8, 2018 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants