Macro Elasticity result missing for start year

[martinholmer]

When start year is 2017 and you do a static simulation of a reform that is implemented in 2017, you see differences in taxes beginning in 2017. When you then do a Macro Elasticity dynamic simulation for that reform, the percentage GDP change for 2017 is shown as NA.

Why is that? When I use a Python script to generate estimates of the percentage change in GDP, I get sensible results for 2017 as well as the subsequent nine years. Why isn't TaxBrain showing the 2017 estimate?

This behavior is exhibited by the current production version of TaxBrain as well as the 1.0.3 release candidate. Here is what the results look like:

Also, Macro-Elasticity issues #617 and #673 are still unresolved.

@GoFroggyRun, can you fix these problems?

@MattHJensen @hdoupe @GoFroggyRun

[GoFroggyRun]

Thanks for noticing this @martinholmer. After taking a close look at the issue, the lines here actually adds the value NA for the first element on purpose. And the macro elasticity page has been like this since online (a.k.a the first run).

I did a bit testing here: removing this value will result in dimensional error, since the elasticity_gdp data now only have 9 values, while the table in the output page is looking for 10 columns. I have a couple questions here:

1. Why are we recording only 9 values of GDP elasticity, instead of 10 years, and adding a NA for the first year.
2. Is the result table regularized at all? It is possible that we are mis-matching values and years here?

cc @martinholmer @MattHJensen @hdoupe

[martinholmer]

@GoFroggyRun said in issue #680:

I did a bit testing here: removing this value will result in dimensional error, since the elasticity_gdp data now only have 9 values, while the table in the output page is looking for 10 columns.

Do you mean the TaxBrain database (that holds results from prior runs) has only 9 years of GDP percentage change for each run?

I have a couple questions here:

Why are we recording only 9 values of GDP [percentage change], instead of 10 years, and adding a NA for the first year?

Could it be as simple as a mistake?

The following test in the test_celery_tasks.py file seems to indicate that the first budget year (that is, year=0) is expected to have a numerical value. Otherwise, what would be the point of calling the function and computing a GDP percentage change estimate if the year=0 value was always going to be NA?

def test_elasticity_gdp_task_async():
    with patch_mtr():
        first_budget_year, year = 2016, 0
        user_mods = {'policy': {2016: {'_II_rt3': [0.31, 0.32, 0.33],
                                       '_II_em_cpi': False,
                                       '_II_rt4': [0.39, 0.4, 0.41]}}}
        gdp_elasticity = dict(first_year=2018)
        user_mods = {"reform": json.dumps(TAXIO_JSON), "assumptions": json.dumps(ASSUMPTIONS_JSON)}
        result = ct.elasticity_gdp_task_async.delay(year, user_mods,
                                                    first_budget_year,
                                                    gdp_elasticity)
        assert 'elasticity_gdp' in result

[talumbau]

Hi all. @MattHJensen and @Amy-Xu would probably have the best answers on this, but the intention of this calculation was always that the "year 0" part of the calculation did not make sense. When @martinholmer did a significant refactor of the dropq functions in the Tax-Calculator in this commit on April 25, 2017, he modified the implementation of run_nth_year_gdp_elast in a significant way, perhaps changing the meaning of the calculation entirely. In particular, his changes included the deletion of this line which specifically says that the year 0 calculation does not make sense.

Also as part of that change, he deleted the portion of the test that asserted that the calculation returned N-1 results for N budget years.

So, the full answer to your question would involve looking at the implementation of run_gdp_elast_model prior to the refactor that @martinholmer did several months ago. If this calculation is no longer relevant and/or the desired way to do the calculation, then the results page for TaxBrain should also change. Here, it seems clear that there was not a refactor on the results page for these calculations to correspond to the changes that @martinholmer made in April.

[martinholmer]

@talumbau, thanks for your helpful explanation in issue #680 with respect to TaxBrain displaying NA in the first year on the Macro-Elasticity results page.

The key is the old comment line which said this:

# Only makes sense to run for budget years 1 through n-1 (not for year 0)

When I was working on Tax-Calculator pull request 1314, which I opened on Apr 26, 2017, and merged on May 2, 2017, I couldn't think why it made no sense to call run_nth_year_gdp_elast_model with year_n=0. There was no explanation of why it didn't make sense in the dropq.py code or in the macro_elasticity.py code.

But maybe I wasn't thinking correctly then.

Why exactly does it make no sense in year zero?

@MattHJensen @Amy-Xu

[Amy-Xu]

My memory is a bit rusty on this. It seems to me that a marginal tax rate change will lead to a GDP growth rate change of next year (page 20 of Barro and Redlicks, 2009). So we can estimate elasticity starting from year 1 instead of 0. But I could be wrong.

@martinholmer @MattHJensen

[MattHJensen]

My memory is a bit rusty on this. It seems to me that a marginal tax rate change will lead to a GDP growth rate change of next year (page 20 of Barro and Redlicks, 2009). So we can estimate elasticity starting from year 1 instead of 0.

I think we could accomodate year 0, by calculating MTRs under year -1 under current law, but we would need a special case for 2013, because we can't calculate MTRs for 2012.

[martinholmer]

@Amy-Xu said in TaxBrain issue #680:

It seems to me that a marginal tax rate change will lead to a GDP growth rate change of next year (page 20 of Barro and Redlicks, 2009). So we can estimate elasticity starting from year 1 instead of 0.

Actually, equation (1) on page 14 of the Barro-Redlick paper makes it clear that they are estimating an equation in which the current year's change in GDP depends on the prior year's change in the average marginal tax rate. I'm quite sympathetic to this way of thinking about simulating the economic growth effects of a tax reform. So, I think we should revise both Tax-Calculator and TaxBrain to work that way.

But the problem is that what Barro-Redlick specify in their lagged equation (1) is not what TaxBrain or Tax-Calculator was doing before I made the changes in Tax-Calculator pull request 1314. If the code in the Tax-Calculator macro_elasticity.py file had been calculating the GDP change in year t by using the average marginal tax rate change in year t-1, then the reason for putting an NA in the first year of the TaxBrain table would have been immediately clear. Actually, the NA is confusing: the lag argument implies quite clearly that the GDP change in the first year of a reform is 0.0 (not NA). So even the NA used in TaxBrain hides the lagged macroeconomic effect assumption. In other words, there never has been any lag logic in Tax-Calculator or TaxBrain.

So, given this information and the realization that neither the pre-1314 nor the post-1314 logic incorporates a lagged macro effect of a tax reform, what do we need do in order to get things working correctly?

First, and most importantly, the logic in the Tax-Calculator macro_elasticity.py file needs to be fixed so that the returned proportional GDP effect of the reform for year t is computed using the reform's effect on the average marginal tax in year t-1.

Second, the display of Macro-Elasticity results in TaxBrain needs to be changed so that all ten of the budget years have numerical values. For reforms that begin in the first budget year, just that first year would have a value of zero (not NA). But a reform that starts in the third budget year would have zero GDP change in the first, second, and third budget years. And reforms that start before the first budget year (as can be specified using an uploaded JSON reform file) will have non-zero GDP changes in all ten budget years. If we want to do this correctly, it seems as if the TaxBrain database would need to be changed so that it holds ten (not nine) values of GDP change. This change would be fairly easy because the new first year value in all past runs has been zero.

Does this approach to fixing things seem sensible?

If so, who has the knowledge about how to change the TaxBrain database of past run results?
I'll be happy to make the Tax-Calculator changes although it may take some doing to incorporate lag logic.

@MattHJensen @feenberg @Amy-Xu @andersonfrailey @hdoupe @GoFroggyRun @talumbau

[Amy-Xu]

@MattHJensen I thought only when there's a MTR shift, presumably because of a reform, the calculations of GDP growth rates change would make sense. In other words, if a reform is implemented in 2017, 2017 is year 0 right? At least I assume so. If that's true, 2017 or any prior year's MTR could be calculated but not something we want.

[MattHJensen]

First, and most importantly, the logic in the Tax-Calculator macro_elasticity.py file needs to be fixed so that the returned proportional GDP effect of the reform for year t is computed using the reform's effect on the average marginal tax in year t-1.

Second, the display of Macro-Elasticity results in TaxBrain needs to be changed so that all ten of the budget years have numerical values. For reforms that begin in the first budget year, just that first year would have a value of zero (not NA). But a reform that starts in the third budget year would have zero GDP change in the first, second, and third budget years. And reforms that start before the first budget year (as can be specified using an uploaded JSON reform file) will have non-zero GDP changes in all ten budget years. If we want to do this correctly, it seems as if the TaxBrain database would need to be changed so that it holds ten (not nine) values of GDP change. This change would be fairly easy because the new first year value in all past runs has been zero.

That definitely makes sense and fits with my take on the consensus thinking. And thanks to @martinholmer for work on PSLmodels/Tax-Calculator#1579 in this direction.

--

Separately, my take on the discussion in this issue is that it probably doesn't matter whether something was implemented properly at one time in the past and then broken, or always broken, or never thought up, or never improved, or anything else. It doesn't seem worth spending time to figure out the chain of events, and following those links can distract us from doing our best job at the tasks at hand. I definitely see how it is useful to dig up and understand the original thinking and intent, as those can inform our present thinking and present intent, but that's a completely different thing.

We have a lot of work ahead of us to improve PolicyBrain, and I -- one of many I imagine -- am super excited to be sitting here in front of my computer a year from now and seeing what the software, the user experience, the infrastructure, and even our processes for collaborating together on the project, have become. Just look at the quantity and quality of the commits and discussion that have been happening! We'll need to make a lot of progress and move fast over the next few weeks and months, so it's best to keep the conversations here focussed and positive.

@martinholmer @feenberg @Amy-Xu @andersonfrailey @hdoupe @GoFroggyRun @talumbau

[feenberg]

On Fri, 6 Oct 2017, Matt Jensen wrote: First, and most importantly, the logic in the Tax-Calculator macro_elasticity.py file needs to be fixed so that the returned proportional GDP effect of the reform for year t is computed using the reform's effect on the average marginal tax in year t-1.

I haven't seen any discussion of this. Is this about fiscal year v calendar year? Or a lag in reaction to changed incentives? Something else? dan feenberg

[martinholmer]

@feenberg said asked:

I haven't seen any discussion of this.

There is an extended discussion on GitHub in issue #680. Go there to see the whole discussion.

Is this about fiscal year v calendar year? Or a lag in reaction to changed incentives? Something
else?

About "a lag in reaction to changed incentives".

[martinholmer]

Tax-Calculator pull request 1579, which will be included in taxcalc>=0.12.0 packages, facilitates the TaxBrain changes discussed in issue #680.

The macro-elasticity lag logic introduced in 1579 implies a need to revise TaxBrain in several ways:

First, the run_nth_year_gdp_elast_model function needs to be called for all ten budget years using a loop something like this:

for year_n in range(0, 10):
    gdp_change[year_n] = run_nth_year_gdp_elast_model(year_n, start_year, ...)

Second, the numerical values for GDP change need to be shown on the Macro-Elasticity results page for all ten years (that is, the NA needs to be removed).

And third, all ten numerical values of GDP change need to be saved in the TaxBrain run database.

@MattHJensen @hdoupe @GoFroggyRun

[hdoupe]

@martinholmer said:

First, the run_nth_year_gdp_elast_model function needs to be called for all ten budget years using a loop something like this:

I'm looking over the TaxBrain logic for the macro elasticity simulation now. Just to clarify, run_nth_year_gdp_elast_model is called 9 times for years start year + 1 through start year + 9. I think the only change in logic would be adding a call for the start year.

Second, the numerical values for GDP change need to be shown on the Macro-Elasticity results page for all ten years (that is, the NA needs to be removed).

I think this will be resolved once we call run_nth_year_gdp_elast_model for year 0.

And third, all ten numerical values of GDP change need to be saved in the TaxBrain run database.

Currently, this result is what's saved after a run:
{u'elasticity_gdp': {u'gdp_elasticity': [u'NA', u'0.00425', u'0.00442', u'0.00490', u'0.00447', u'0.00431', u'0.00434', u'0.00432', u'0.00467', u'0.00432']}}

This should also be resolved once we set a value to the year 0 result.

Thanks for outlining the changes that will be required by TaxBrain.

[martinholmer]

@hdoupe, I think you have a correct understanding of the details of issue 680 as expressed in this comment.

[hdoupe]

#680 has been resolved. See: