Apply wage growth rates to 'Max Taxable Earnings for Social Security'

[Amy-Xu]

In this PR, wage growth rates replaced the CPI rates for this _SS_Earnings_c. Two things worth notice:

• This wage growth rates are only applied to this Max Taxable Earnings, but not any threshold for Social Security Tax. Not quiet sure whether we need to inflate "Threshold for Social Security benefit taxability 1" and "Threshold for Social Security benefit taxability 2" at the same rate or not.
• The way we apply wage growth rates is exactly the same as CPI rates. By that I mean we apply the growth rate for 2013 to 2014 on the 2014 parameter to get 2015 value.

@MattHJensen @martinholmer Could you review? Thanks!

[MattHJensen]

@martinholmer:

@Amy-Xu and I thought it would be good to do something provisional for this while you flesh out your ideas in #369.

[MattHJensen]

@Amy-Xu, it looks like this branch is on top of the branch from #424. In the future it is probably better to split them when possible. https://git-scm.com/docs/git-cherry-pick is really helpful if you realize too late.

[martinholmer]

@Amy-Xu said:

This wage growth rates are only applied to this Max Taxable Earnings [MTE], but not any threshold for Social Security Tax. Not quiet sure whether we need to inflate "Threshold for Social Security benefit taxability 1" and "Threshold for Social Security benefit taxability 2" at the same rate or not.

The current_law_policy.json file is correct: MTE is indexed, but the other two threshold parameters are not indexed to anything (that is, they are constants over time by design in the 1983 social security reform). If these two OASDI benefit taxation threshold parameters were ever to be indexed (which is not likely in the current political environment), I think it is extremely likely that they would be indexed to price inflation (not wage growth).

[martinholmer]

@MattHJensen said:

@Amy-Xu and I thought it would be good to do something provisional for this while you flesh out your ideas in #369.

That's fine.

[martinholmer]

@Amy-Xu said:

@MattHJensen @martinholmer Could you review? Thanks!

I agree with Matt: the code changes are way too confusing with the GDP thing going on. Can you prepare a new pull request that focuses only on the issue of adding wage growth rates in addition to the price inflation rates that are already in the master branch?

When you do prepare that new pull request, remember what the conclusion from the prior conversation was: @MattHJensen stressed the need for the Policy class to have default price inflation rates and default wage growth rates that are exactly the same as the rates implicit in the blowup factors. IMPLICATION: it is a good idea to set the default rates in the Policy class, but there needs to be a unit test that checks that those two Policy default rates are exactly equal to the ones implicit in the blowup factors file. Maybe there is a test for this, but in my (probably too quick) review of the code changes, I didn't see one.

My other concerns all have to do with variable naming. This doesn't affect the logic of the code, but it does influence the readability of the code. Readability is an important issue because now that TaxBrain is being used by people (including a number of economists), we are inviting them to read the Tax-Calculator code. I think we owe it these people (and to ourselves as the main developers) to use standard economic terminology when we name economic variables. Here are some of the variable naming problems that are likely to put off economists looking at the code:

Policy class __rates needs to be changed to something like __pirates for price inflation rates.

Policy class __wage_rates needs to be changed to __wgrates for wage growth rates.
[To an economist, a wage rate is a LEVEL, not a GROWTH RATE.]

Policy class default_wage_inflation_rates() needs to be changed to default_wage_growth_rates() to avoid over using the term inflation which (without an adjective) is taken by most to refer to price inflation.

There may be other variable name changes that would be desirable, but these are important ones that will reduce the amount of confusion people have when they read the Tax-Calculator code.

[MattHJensen]

@Amy-Xu, I just merged #424. Could you merge master into this branch and see if that cleans up the commit history? You may need to close this PR and open a new one.

[Amy-Xu]

@martinholmer Just cleaned this PR up and right now the diff page only includes the code changes relevant to wage growth rates. I also renamed the variables as well. Could you take a look when you get a chance?

@MattHJensen Do you think it's fine to keep working on this PR instead of opening a new one after I cleaned it up?

[MattHJensen]

Do you think it's fine to keep working on this PR instead of opening a new one after I cleaned it up?

Yep. This one is much easier to read now.

[martinholmer]

@Amy-Xu said:

@ martinholmer Just cleaned this PR up and right now the diff page only includes the code changes relevant to wage growth rates. I also renamed the variables as well. Could you take a look when you get a chance?

Amy, my only problem is that wage_rates is, for most economists, a very confusing term for wage growth rates. A wage rate, to most economists, is the LEVEL of wages in a year, not the RATE OF GROWTH in wages. So, to avoid massive confusion, I strongly urge your to change wage_rates to wage_growth_rates (or something like that).

In the parameter_base.py code, you might want to consider setting an indexing_rates variable, which would be in almost all cases equal to [price] inflation rates, but in the one case of the OASDI MTE be equal to the wage growth rates. Then you can call the expand_array function once with inflation_rates=indexing_rates. This is logically equivalent to what you are doing, but cuts down the duplicate code in multiple branches, and hence, improves readability of the code.

[Amy-Xu]

@martinholmer Indeed wage_rates is very confusing as you pointed out. I renamed it to wage_growth_rates. Thanks for the suggestions on indexing_rates. This way is definitely clearer than adding a bunch of if-else loop inside the for loops. I wrote two functions to return the indexing_rates for different parameters. Could you take a look at them?

[martinholmer]

@Amy-Xu said:

Indeed wage_rates is very confusing as you pointed out. I renamed it to wage_growth_rates. Thanks for the suggestions on indexing_rates. This way is definitely clearer than adding a bunch of if-else loop inside the for loops. I wrote two functions to return the indexing_rates for different parameters. Could you take a look at them?

I agree. These enhancements look much clearer now. Thanks for making the changes.

[MattHJensen]

@Amy-Xu, this is great. Could you show how it affects payroll tax liabilities over the budget window before we merge? (I anticipate that they should be higher with this PR than under master.)

[Amy-Xu]

Payroll tax liabilities indeed seem to be higher in the out years.

Master:

This PR:

[MattHJensen]

Thanks @Amy-Xu! Merging.