[WIP]Adjust economic growth rates

[Amy-Xu]

This PR added functionality for the type of sensitivity analysis to:

• increase/decrease economic growth by an X percentage
• to set it to at a certain target rate.

Two functions in records.py are relevant.

factor_adjustment(percentage, year) will take the user-specified percentage adjustment for one year and apply this adjustment to all dollar amount factors. For example, if users set this percentage at 0.01, then it means the initial annual growth rate of 0.03 will be increased to 0.03 * (1 + 0.01) = 0.0303.

factor_target(target, year) will take the target, divide it by the GDP growth rate of that year, and get a general target ratio. Then apply this ratio to all other factors. For example, if our user expects GDP grows at 4% a year, and current rate is 2%. Then the ratio would be 4% over 2% which is 2, so all other rates would be doubled for this particular year. This ratio varies by year as current GDP growth rates are different. @feenberg @MattHJensen Do you think this is a reasonable way of implementation?

Currently the functions are getting all these adjustment parameters from params.json. I'm aware that @martinholmer is actually refactoring the Record class. So I will definitely rewrite this section after Martin finishes his part. Tests are also postponed due to the same reason.

@PeterDSteinberg (Hi I'm Amy:)))) Matt told me you are working on the webapp side of our project. So I guess it might be helpful to take a glance at this PR. This is how I implement the idea. Ultimately we want users to be able to input adjustment and targets from webapp. Please let me know if you have any suggestions to make the connection to the front end easier.

Finally, I ran a few experiments and here are the results.

Baseline:

All experiments are starting from 2016.
Increase growth by 1%:

Decrease growth by 1%:

What if the economic growth is 4%?

How about 6%? (I was very entertained by this idea, just as the proposal of building a wall. But then, suddenly realized this actually brought our projection way closer to CBO's baseline...........)

Welcome comments/suggestions from everyone!

[MattHJensen]

Very nice, @Amy-Xu. I'll look through this closer tomorrow.

Currently the functions are getting all these adjustment parameters from params.json. I'm aware that @martinholmer is actually refactoring the Record class. So I will definitely rewrite this section after Martin finishes his part. Tests are also postponed due to the same reason.

@martinholmer and @PeterDSteinberg: Amy is going to take a cue from the work Peter is doing to make the behavior parameters available from a Behavior class as described here: #367 (comment)

[Amy-Xu]

As @MattHJensen pointed out, the target economic growth rates are usually referred in real terms. I added our current CPI rates to the user defined targets before changing the Stage I factors. Here're the result tables.

Reform starts in 2015
real growth == 0.04

real growth == 0.06

[martinholmer]

@Amy-Xu,

So, does the phrase "real growth == 0.04" imply that the aging process assumes earnings (e00200) grow at a rate of (1.04*(1+inflation_rate))-1.0?

[martinholmer]

@Amy-Xu,

I asked late yesterday:

So, does the phrase "real growth == 0.04" imply that the aging process assumes earnings (e00200) grow at a rate of (1.04*(1+inflation_rate))-1.0?

After looking at the blowup factors in the StageIFactors.csv file, I can see that the answer to my question is no. So let me ask a different question: What does the phrase "real growth == 0.04" mean? What is being assumed to grow at four percent a year?

[Amy-Xu]

@martinholmer GDP is assumed to grow at 4% in real terms (no inflation included).

[MattHJensen]

@martinholmer, let me provide a bit more explanation. We want the user to be able to adjust the baseline growth rate assumed by data extrapolation. One way to do that is to say, "I think the economy will grow x% slower than in the default extrapolation process." We allow the user to do this through factor_adjustment(), which will take every blowup factor rate and reduce it by x% (not x percentage points). That could be a bit confusing for users, though, because there is not really anything that can be viewed as a "single growth rate" in our data extrapolation -- different variables receive different blowup factors. After you say you want things to be x% lower, we can't give you one number that says what the growth rate ended up being. Confusing.

However, one of the blowup factors we do have is GDP growth. That GDP number was taken from a CBO document where we also took many other blowup factors (including, for example, wage growth), so, presumably, the ratio between wage growth and GDP growth is meaningful. Factor_target() takes advantage of this. We allow the user to say what they think the GDP growth rate is, and then adjust the GDP blowup factor to match that number and adjust all of the other blowup factors (including wage growth) to maintain the ratio between GDP growth and the other factor's growth.

So in summation, both ways of changing the baseline dataset provided by this PR will end up affecting wage growth. One method changes wage growth (and blowup factors) directly, the other method changes wage growth (and other blowup factors) to maintain a relationship between those factors and the GDP growth factor.

[feenberg]

On Thu, 1 Oct 2015, Matt Jensen wrote:

@martinholmer, let me provide a bit more explanation. We want the user to be
able to adjust the baseline growth rate assumed by data extrapolation. One
way to do that is to say, "I think the economy will grow x% slower than in
the default extrapolation process." We allow the user to do this through
factor_adjustment(), which will take every blowup factor rate and reduce it
by x% (not x percentage points). That could be a bit confusing for users,

I disagree. The user-supplied number should be added to the CBO forecast.
If I think wages will grow from 100 to 110, and CBO thinks it will grow
from 100 to 105, it is clear what the user wants for wage growth. But
suppose CBO thinks mortgage interest won't change, what growth rate should
we put on mortgage interest? We only gave the user one parameter. I expect
he would think that mortgage interest would grow. After all, the reason
CBO didn't grow it might have been an anticipated reduction in interest
rates. Additional economic growth could counteract that.

dan
617-863-0343

[MattHJensen]

@feenberg, I see your point that we should allow the user to specify a percentage point change rather than a percent change for the growth rate.

It seems like we could apply the same principle to the GDP growth rate target feature. When the user supplies a GDP growth rate, then rather than applying the ratio between the user supplied GDP growth rate and CBO's GDP growth to all other blowup factors, we would apply the difference.

[MattHJensen]

@Amy-Xu, after I merge https://github.com/MattHJensen/taxcalc/pull/5, you will need to update this PR to follow 'new class' style that will be displayed in #367. This will allow us to take the new non-tax-law params out of params.json. It might be worth you looking into how parallelization works in dropQ/webapp as well (and chatting with @PeterDSteinberg for more background as necessary) to ensure that this will play nicely with the webapp. I'll let you know when #367 is ready to be used as an example, but just wanted to give you a heads up.

[MattHJensen]

We should have some param validation that guarantees the user doesn't change both of these at the same time.

[MattHJensen]

Ok @Amy-Xu, you can now model this off of behavior.py and behavior.json in master.

[MattHJensen]

@Amy-Xu, it looks like #371 is moving pretty quickly. Probably best to wait on refactoring this one until #371 is merged.

[Amy-Xu]

Got you.

[MattHJensen]

@PeterDSteinberg could you take a look at this PR to see if there is anything besides #371-related issues that you think will need to be taken care of for it to play nicely with the webapp? In particular I am concerned about the fact that we are calling factor_adjustment() and factor_target() during increment year. My understanding is that our parallelization strategy has us incrementing years before we get any user input from TaxBrain, but we need to get params for factor_adjustment() and factor_target() from the user.

I think with some algebra this could be implemented in such a way that factor_adustment() and factor_target() are called after increment year, rather then during, but @PeterDSteinberg, it would be nice to have your verification that this reworking is necessary.

[MattHJensen]

@Amy-Xu, can this PR be closed now in favor of #383?

[Amy-Xu]

yea, closing.