Issues with 'cpi_offset' parameter

[GoFroggyRun]

Both the House bill and the Senate bill adopt chained-CPI indexing. While working on the reform file upload option and TB's GUI input work, I realized that there might be some issues with how this parameter works.

To realize chained-CPI indexing for year 2018, the cpi_offset parameter needs to be set to -0.0025 in year 2017. However, both reforms (House and Senate) actually take affect in 2018. In this case, to implement either reform in TB's GUI, users have to always begin with year 2017. So each input field other than cpi_offset has to have an extra *, indicating no change in 2017's law. Also, the result table would build an extra column for year 2017 with no change whatsoever. Does this really make sense?

A couple solutions to simplify the issue:

1. Come up with some ways to allow users to edit previous year parameter on TB's GUI page, just like what we have done to allow future year edits.

2. Modify how cpi_offset parameter work in tax-calculator by simply implementing the chained-CPI indexing one year head of reform year specified.

@martinholmer @MattHJensen @hdoupe

[martinholmer]

@GoFroggyRun said we could:

Modify how cpi_offset parameter work in Tax-Calculator by skimpily implementing the chained-CPI indexing one year head of reform year specified.

I view this as a very bad idea and I'm not even sure how it would work. Tax-Calculator has no problem with a reform that starts before the ten-year budget window. It is the design of TaxBrain that is the problem. When I started on this project, TaxBrain required all reform provision to start in the first budget year (that is, there was no * capability to specify delayed implementation of a reform provision).

[martinholmer]

@GoFroggyRun said we could:

Come up with some ways to allow users to edit previous year parameter on TaxBrain's GUI page, just like what we have done to allow future year edits.

And @martinholmer said:

Tax-Calculator has no problem with a reform that starts before the ten-year budget window. It is the design of TaxBrain that is the problem.

One way to think about how to redesign TaxBrain, is to focus on one particular limitation of TaxBrain: the concept of "Start Year" has two conceptually distinct meanings. In TaxBrain, "Start Year" means the first year of the reform and it also means the first year of the ten-year budget window (for which tax results are shown). It seems to me that those are distinct concepts and we don't necessarily want them to be equal in all cases.

So, why not have two start years on the TaxBrain GUI page? One would be the "Reform Start Year" and the other would be the "Output Start Year". Or maybe there are better labels for these two distinct start years.

@hdoupe @MattHJensen

[MattHJensen]

So, why not have two start years on the TaxBrain GUI page? One would be the "Reform Start Year" and the other would be the "Output Start Year". Or maybe there are better labels for these two distinct start years.

@martinhomer's proposal might be best, and that option would certainly be an improvement from where we are now because it would at least enable users to generate 10 years of output for the TCJA -- currently they can not.

But it would not solve one of the problems @GoFroggyRun mentioned: "each input field other than cpi_offset has to have an extra *, indicating no change in 2017's law" and it would create a fairly significant source of user error, I imagine. Users might change the Output Start Year and forget to change the Reform Start Year or similar.

So I wonder if anyone is aware of users encountering a problem like the one we face now before, where the user wants a different reform start year than output start year? If not, the simplest solution might be to just change the definition of cpi_offset parameter so that changing the 2018 value of cpi_offset changes the 2018 value of parameters, but I don't know how difficult it would be to implement this in tax-calculator.

One advantage of separating the reform start year and the output start year (@martinholmer's proposal) is that 5 years for now, say, it would be very easy to see how the TCJA implemented way back in 2017/2018 affects the forward looking 10 year budget outlook.

So actually, I think my preference would be to do both: separate the Output Start Year from the Reform Start year and redefine cpi_offset in tax-calculator. The redefinition of cpi_offset should be a higher priority because it would solve immediate problems for users analyzing TCJA, and the separation of Output Start Year and Reform Start year could happen on a slower time frame.

--
(An alternative option (which I am not terribly fond of but will present for others) would be to add a new input character that indicates that the proceeding value is for a previous year to the start year. For example, if we chose ; for such a parameter and the start year is 2018, then -0.0025; would indicate that the cpi indexing is set in 2017.)

[hdoupe]

I agree with @martinholmer's proposal of having a start year and an output start year.

I also agree with @MattHJensen that the cpi_offset parameter should be redefined in Tax-Calculator if this is possible. It doesn't make much sense to me to have a parameter not have any effect until a year after it's activated.

[martinholmer]

@hdoupe said:

I also agree with @MattHJensen that the cpi_offset parameter should be redefined in Tax-Calculator if this is possible. It doesn't make much sense to me to have a parameter not have any effect until a year after it's activated.

I have no idea how to "redefine" the cpi_offset parameter given the way Tax-Calculator does price-inflation and wage-growth indexing. The current indexing logic was built in at the very beginning of the project before I got involved with Tax-Calculator.

[GoFroggyRun]

I agree with @martinholmer, @MattHJensen and @hdoupe that having a start year and an output year on TaxBrain would be a huge improvement. We definitely want to incorporate such enhancement after things get cool down a bit.

My apologies that my initially suggestion was not clear enough. Indeed, after looking into the price-inflation and wage-growth indexing mechanisms planted in tax-calculator, I agree with @martinholmer that modifying these logic is a bad idea. And I have no idea how to do that either.

In fact, what I have in mind, instead of dealing with those convoluted logic, is to take a roundabout approach. After reforms are read into tax-calculator, but before implementing any of them, are we able to apply some special treatment to cpi_offset parameter in the way that, if it were specified in year n, it would be processed as n-1 in the calculator? I understand this might not be an elegant solution, but, to not deal with any indexing logic, it would seem a reasonable one. Also, given I am not very familiar with the indexing logic in tax-calculator, it is very likely that my proposal is implausible.

@martinholmer, does the approach make sense to you? Would that allow 1-year lag in specifying cpi_offset-related reforms without touching any of the indexing logic?

[hdoupe]

It seems like the consensus is that we need both a parameter (or reform) start year and an output start year. The interface would then look something like this:

I think that we would only have to make changes on the TaxBrain side. Instead of passing the reform start year to TC, we would send the ouptut start year as the start_year in parameter in tbi.py.

While we are adding this functionality, I think we should allow for the user to select a start year (output and reform) for any year up to 2027. The final year of output would still be 2027 or output start_year + 9, but the user would have an option to show less years. The output tables already allow us to do this:

[hdoupe]

@GoFroggyRun and I were discussing implementation issues with adding an output start year. We circled back to the idea of adding a special reverse character. Here's our conversation:

From @GoFroggyRun

Also, having separate reform year and output year is not the only solution: the CPI offset parameter still has to be specified in 2017, and users will have to add an extra * for each reform provision other than CPI offset parameter, which can be annoying and confusing. An alternative approach would be to allow for previous year GUI input edits (for example in start year 2018, we allow users to specify 2017 and previous parameter values in some format). This alternative approach doesn’t involve separating reform year and start year, and would better solve the problem, at least for the moment, in my opinion. I’m not sure, however, how difficult this approach is.

What do you think about this alternative?

From me:

I agree that separating the reform year and output years is not the only solution. However, I think it gives us some flexibility that we may want in the future.

I’m not a huge fan of adding a reverse parameter that pushes the following parameter back a year. The nice part about the GUI interface is that you don’t need to know how to program in order to use it. So, I’m wary of adding another special character and creating our own little programming language.

On the other hand, adding a reverse character seems like a pretty simple addition. Further, if we implement this character we could implement the TCJA in a pretty straight forward way: Enter cpi_offset as “<,-0.0025” and fill in the other parameters like usual (I’m thinking “<” would be a good character, but I’m open to other suggestions)

If we add this parameter, we should only allow it to be used as the first character in the string. We don’t want to implement some function that has to figure out what this means: 7000,,,8000,<,<,10000,<,* etc.

From @GoFroggyRun:

HANK: I agree that separating the reform year and output years is not the only solution. However, I think it gives us some flexibility that we may want in the future.

SEAN: Right. I agree. This is definitely something nice to have.

HANK: I’m not a huge fan of adding a reverse parameter that pushes the following parameter back a year. The nice part about the GUI interface is that you don’t need to know how to program in order to use it. So, I’m wary of adding another special character and creating our own little programming language.

On the other hand, adding a reverse character seems like a pretty simple addition. Further, if we implement this character we could implement the TCJA in a pretty straight forward way: Enter cpi_offset as “<,-0.0025” and fill in the other parameters like usual (I’m thinking “<” would be a good character, but I’m open to other suggestions)

SEAN: Me neither haha. But it seems to me that this is an easy way to deal with the special case for parameters like CPI offset --- hopefully we won't have too many of them. If having such addition is simple, the only thing we need to worry about is to come up with some symbol straightforward yet special enough. Let's move the discussion to Github and see if others have any better ideas.

HANK: If we add this parameter, we should only allow it to be used as the first character in the string. We don’t want to implement some function that has to figure out what this means: 7000, * , * , 8000,<,<,10000,<,* etc.

SEAN: This is exactly what I have in mind as well.

HANK: Do you mind if I move the last two comments to github #763?

SEAN: Not at all.

cc @MattHJensen @martinholmer @MaxGhenis

[GoFroggyRun]

I guess the only question remains regarding "reverse editing" is what the syntax should look like.

The <, symbol @hdoupe suggested is a good one. If <, were adopted, the "reverse editing" would be something look like: (just some random example)

-0.001 <, -0.0025 <, *, 0, *, *

or, if we were using <,<,

-0.001 <,< -0.0025 <,< *, 0, *, *

@hdoupe Is this what you were thinking? What do you think of the <,< symbol?

[hdoupe]

@GoFroggyRun asked

@hdoupe Is this what you were thinking? What do you think of the <,< symbol?

Sort of. I think we should impose some strict rules on how this symbol can be used so that we can keep everything simple.

1. It can only be used at the beginning of the string.
2. It can only send a parameter back one year (this rule could be relaxed fairly easily)

For example, if you set the start year as 2018 and the cpi_offset parameter to "<,-0.0025", then this sets the cpi_offset to -0.0025 in 2017.

Implementing this is pretty straight forward. In fact, I just put together a prototype. I'll open a PR in a few minutes.

I think adding a reverse parameter and the ability to specify a different output year adds significant flexibility to TaxBrain. Consider a reform that goes into effect in 2018, but the vast majority of it's parameters do not take effect until 2020. You could set the reform year to 2020 and the output year to 2018. You could then use the "<" character to enter the parameters that take effect in 2018 and simply enter the other parameters with out having to use a bunch of "*" characters to get them up to 2020.

I guess the argument against this character is that if you are going to learn how to use this character then wouldn't it be easier just to write a json file?

[MattHJensen]

I think adding a reverse parameter and the ability to specify a different output year adds significant flexibility to TaxBrain.

Definitely agreed.

I guess the argument against this character is that if you are going to learn how to use this character then wouldn't it be easier just to write a json file?

I don't think so -- there are significant other benefits of the GUI, such as being able to view documentation, current-law values, and the reform all in one place.