New BRC to-do list

[codykallen]

After the refactoring in #50, it's time to create a new to-do list for BRC.

1. Refactor the mini_combined.py file This file acts as a workhorse for calculating the cost of capital. This is very similar to what B-Tax does, and as such it may be useful to make it to some degree interchangeable with B-Tax. However, my mini version is distinct from B-Tax in that I use different equations for calculating the cost of capital; my equations allow for nonconstant tax rates, something certainly relevant in the context of the expiration of that pass-through exclusion (Section 199A) in the TCJA.

2. Alternate version of the legal response I'm not satisfied with the current approach. In reality, any effect should not occur instantaneously, and it needs to occur without overlapping the investment effect.

3. Improve the AMT model The current version is reasonable from economic modeling, but I want to run some further tests to ensure that it is robust to larger changes in tax rates.

4. Add an international tax model With the new structure of BRC, I image the best approach to implementing this will involve creating a new class, the MultinationalEnterprise, to handle changes in profit shifting and the TCJA's new international taxation provisions.

5. Deal with the other_params dictionary These parameters are tricky to deal with because they involve some strange changes. It may be helpful to refactor the entire approach to handling policy parameters in BRC.

6. Switch to one year at a time With the new structure, this should be somewhat easier to do. It may also make it easier to deal with the other_params issue.

I expect there are a number of structural changes that need to be made as well. @martinholmer @andersonfrailey @hdoupe, would you care to list some of those areas that need to be refactored further?

[martinholmer]

@codykallen said in issue #52:

5. Deal with the other_params dictionary These parameters are tricky to deal with because they involve some strange changes. It may be helpful to refactor the entire approach to handling policy parameters in BRC.

What exactly is "tricky" about the other_params? Guess I don't know what you mean by "strange changes."

Does your code include any policy parameters that are inflation indexed?

Since you are already importing the taxcalc package, have you considered using its parameters capabilities? That's what the code in the Behavioral-Responses repo does.

@hdoupe @andersonfrailey

[codykallen]

@martinholmer asked:

What exactly is "tricky" about the other_params? Guess I don't know what you mean by "strange changes."

As an example, let's use newIntPaid_corp_hc. This is a haircut on the deductibility of interest paid on debt originated on or after the year associated with it (each of these other parameters is a year:mod pairing). However, the deduction does not apply to interest paid on debt originated before that year. Although I would not recommend such a policy myself, it's potentially important to transition policy.

Alternatively, consider oldIntPaid_corp_hc, which is a haircut on the deductibility of interest paid after the associated year on debt originated before the given year. Such a policy would be politically difficult to enact, but perhaps economically useful as a tax on existing capital but not on new capital.

I expect the best way to deal with these is to split each "other" parameter into two separate parameters.

@martinholmer also asked:

Does your code include any policy parameters that are inflation indexed?

No.

@martinholmer also asked:

Since you are already importing the taxcalc package, have you considered using its parameters capabilities?

Yes, but I think that would be useful/applicable only after switching to calculating one year at a time.

[codykallen]

This PR is out of date, so I'm closing it.