All params in calculate.py should be indexed by year about tax-calculator HOT 9 CLOSED

@theofanislekkas and @talumbau, a corollary to this is that the inflation rate / manual override procedure outlined in the discussion of #72 should be available for every parameter (the params that stay constant over the window we will just assign a default inflation rate of 0%).

from tax-calculator.

In the same way that we have abstracted the calculator, perhaps we should abstract the the tax parameters into a Model. Each instance of a model would have a current year. Each parameter on the model would have a value for its current year, which would be incremented to get the next year's value for the parameter. Perhaps something like this (assume m is a model that has m.DEFAULT_YR=2012 and _paramX = [0.3, 0.5]:

>>>m.current_year
2012
>>>m.paramX
0.3
>>>m.increment_year()
>>>m.current_year
2013
>>>m.paramX
0.5

The advantage of something like this would mean not seeing the [FLPDYR - p.DEFAULT_YR] throughout the code.

from tax-calculator.

Remember that only dollar amounts are inflated, not rates or percentages.

dan

On Fri, 5 Dec 2014, MattHJensen wrote:

@theofanislekkas and @talumbau, a corollary to this is that the inflation
rate / manual override procedure outlined in the discussion of #72 should be
available for every parameter (the params that stay constant over the window
we will just assign a default inflation rate of 0%).

?
Reply to this email directly or view it on
GitHub.[AHvQVWLgcyIyyKNvYK473FqVldR96x8Yks5nUbE6gaJpZM4DExfD.gif]

from tax-calculator.

On Fri, 5 Dec 2014, T.J. Alumbaugh wrote:

In the same way that we have abstracted the calculator, perhaps we should
abstract the the tax parameters into a Model. Each instance of a model would
have a current year. Each parameter on the model would have a value for its
current year, which would be incremented to get the next year's value for
the parameter. Perhaps something like this (assume m is a model that has
m.DEFAULT_YR=2012 and _paramX = [0.3, 0.5]:

m.current_year
2012
m.paramX
0.3
m.increment_year()
m.current_year
2013
m.paramX
0.5

The advantage of something like this would mean not seeing the [FLPDYR -
p.DEFAULT_YR] throughout the code.

That is attractive - even better than Fortran or SAS which only need
FLPDYR as an argument. But does it slow things down?

dan

?
Reply to this email directly or view it on
GitHub.[AHvQVVwpjhiVjInUFCyHA5-isgV9G9sBks5nUbqngaJpZM4DExfD.gif]

from tax-calculator.

Same reaction as Dan from me.

from tax-calculator.

I have had a chance to get into the details here. One question for @MattHJensen: in your latest changes the the parameters, many of the arrays that are indexed by year are not of length 10 (or, for multi-dimensional arrays, the dimension relevant for year is not of length 10). From this issue, it sounds like the correct thing to do, for certain parameters, would be to automatically scale those variables out by an inflation rate. Some parameters, that are just rates for example, would be expanded out and just replicated 10 times. I will put forward a way of doing this and see what you think.

from tax-calculator.

@talumbau, there are a number of idiosyncratic rounding rules for inflation adjustment (round this up to 50, that down to 25, etc,); it makes sense to use the simple CPI adjustment for the out years, but use the rounded 'actual' params from IRS for past years and the upcoming year. Right now, we have the actual values for 2013, 2014, and 2015 in most cases.

The next step is to take the latest year we have and fill everything out to 2024, inflation adjusting where specified. 2015-2024 will then be the active years for most of our analyses.

It makes sense to keep the historical parameters -- for us 2013 and 2014 -- even though we won't be using them in most analyses because a) they will be a useful resource in and of themselves, b) they will help people who have historical knowledge of the tax code internalize what the parameters mean, and c) they will, eventually, help us to retrospectively test how our models perform. We may want to separate these into another file if they become burdensome. (Similarly, some tax logic in calculate.py will become obsolete over time and we will want to think about how to keep it for retrospection without letting it clutter the calculator too badly, but this is not a pressing issue.)

from tax-calculator.

The commenting in parameters.py in #78 shows which params should be inflation adjusted. (CPI-U) means that the param should be inflation indexed.

from tax-calculator.

This is resolved, and there is better information elsewhere. Closing.

from tax-calculator.