pslmodels / cost-of-capital-calculator Goto Github PK

parameters.translate_param_names() does not handle any of the "check all" parameters that change deprecation schedules for all asset categories. We should update B-Tax to do so or change the CCC UI (see the relates Issue #330 in webapp_public).

cc @PeterDSteinberg

B-Tax yield much different ratios than was CBO (2007) finds. In particular, CBO finds:

1. Fraction of land owned by businesses facing corp tax treatment = 46.8% (B-Tax finds about 18%)
2. Fraction of inventories owned by businesses facing corp tax treatment = 72% (B-Tax finds about 60%).

A place to start is in read_bea.py, where these asset types are attributed across industry and tax treatment.

These should live on the OSPC channel on anaconda.org: anaconda.org/ospc. There should at least be {Linux, Mac, Win64} X {Python 2.7}.

To help with table formatting, we can specify a "units", "divisor" and "decimals" for each of the column metadata dictionaries in btax/param_defaults/btax_results_by*.json. Setting divisor to 1000 and decimals to 0 would round off to the 1000s with no left over.

When setting the depreciation system to economic depreciation for some, but not all, asset classes, the change seems to affect all classes of depreciation.

The Research and Experimentation credit is a significant business tax credit that affects the cost of capital and METRs. B-Tax should thus include the credit in it's calculations.

There are some complications:

1. Even within a given type of intellectual property, the R&E credit does not apply to all expenditures
2. The R&E credit rate is not a flat rate applied to all expenditures - the rules are a bit nuanced.

To solve (1), one might turn to BEA data on fees and costs associated with research and development (by industry and by type of intellectual property) to determine the share to which the R&E credit could be applied. For (2), one might try to get an average effective rate and apply this to all eligible expenditures.

When switching to ADS depreciation, results are nulls.

Changing this parameter didn't seem to affect output. Check that it is working properly and fix if necessary.

To verify that Tax-Calculator and TaxBrain runs get the same answer for the same input, a set of scripts are maintained in the Tax-Calculator repo:

https://github.com/open-source-economics/Tax-Calculator/tree/master/taxcalc/taxbrain

These tests run a selected set of reforms on both Tax-Calculator and TaxBrain and then compare the results. The TaxBrain jobs are run programmatically by using the selenium and chromedriver tools to actually interact with the browser.

We should have a similar set of scripts for B-Tax and CCC to make sure that the same inputs to CCC and B-Tax get the same results.

Add calculations for METRs, etc for inventories to the final outputs. Requires attributing BEA data on inventories across industry using SOI data.

I don't think it will take much time for me to make B-Tax work in both Python 2.7 and 3.*. It will help with interactive usage of taxcalc with Python 3.

Results for METTR for debt financed investments are all N/A. Cost of capital for debt financed non-corporate investment is NA. There should be results reported here.

The current readme file is not complete. When following the current instructions, the user will fail to be able to run B-Tax for at least three reasons:

1. Dependency upon Tax-Calculator.
2. Dependency upon the SOI PUF.
3. They main not be running the correct version of Python.

This leaves a few questions:
a) How should we handle the PUF dependency? We probably want to do what is done with Tax Calculator for users without the PUF.
b) Can we have B-Tax set up so that the PUF (or its replacement) only needs to reside in the TaxCalc directory (and not also in the B-Tax directory)?
c) Can we create a Conda environment and provide users instructions to invoke the environment (as we do for Tax-Calc?)?
d) At what point do we switch to Python 3.x?

cc @MattHJensen @PeterDSteinberg

One could allow for a dynamic analysis of the effects of tax policy on METRs by allowing firm financial policy to be endogenous. This could be done by applying an elasticity of debt financing with respect to taxes. de Mooij has research suggesting some possible values for this parameter.

We need to remove tax exempts from the BEA asset totals. We have a methodology to do this outlined in the METR_Guide, it just needs to be implemented.

Residential structures asset totals are read in correctly from the BEA data, but dropped somewhere along the way. This is affects some visual output as well as the weighed averages created for the industry level output.

The repo needs some housekeeping: there are duplicated files, saved as both .csv and .xls. There are cross-walks that aren't used or could be consolidated. We should consolidate to what is necessary and used and remove the rest.

It would be handy for B-Tax users to be able to generate static METTR bubble plots like this interactive one for any 2 calculators representing baseline and reform.

It would be best to offer both horizontal and portrait layouts.

I saw this in the celery logs just now:

[2016-10-24 14:37:57,320: WARNING/MainProcess] /Users/psteinberg/Documents/AEI/jdebacker_btax/btax/pull_soi_proprietorship.py:162: SettingWithCopyWarning:

This can mean in some cases that the assignment does not take place. Use copy somewhere.

Consider updating the BEA_IRS_Crosswalk.csv document to

1. Be retitled something more appropriate, like "Tax_Deprec_Rules"
2. Have improved formatting to describe the service life, and default depreciation system and method used.

A border adjusted business cash flow tax proposal is under heavy consideration right now. Would it be possible to accomodate a border adjustment in B-Tax? Ideally, there would be a lever for looking at outcomes under different currency adjustments.

For background, see

• https://ospc.shinyapps.io/border-adjustment-calculator/
• http://www.vox.com/2016/12/25/14069822/corporate-tax-border-adjustability
• http://blogs.wsj.com/economics/2016/12/26/republicans-radical-new-business-tax-proposal-simplified-sort-of/

Looks like a file called visuals_plotly.py was not added to git. It is imported by run_btax.py

Our spreadsheet codifying IRS depreciation allowances is not correct. We need to update it. A starting place would be the TxDeprMthd worksheet in the CBO's effective_taxrates.xls.

The NPV of depreciation is not calculating the correct value in the case of no bonus. In particular, the the first year of deprecation is discounted when it should not be. This results in a lower NPV of depreciation deductions and thus larger CC and METRs.

When I run py.test -v -s btax/tests/ with Tax-Calculator master (and latest puf.csv at the top of the directory), I get the following error:

____________ test_each_param_has_effect_slow[btax_depr_25yr_exp-v6] ____________

k = 'btax_depr_25yr_exp'
v = {'description': 'Rate of bonus depreciation on 25-year class property', 'long_name': 'Rate of bonus depreciation on 25-year property', 'max': [-100.0], 'min': [100.0], ...}

    @pytest.mark.parametrize('k,v', [(k,v) for k,v in DEFAULTS
                                      if not ('depr' in k and 'Switch' in k)])
    @pytest.mark.slow
    def test_each_param_has_effect_slow(k, v):
>       tst_each_param_has_effect('slow', k, v)

btax/tests/test_params_have_effect.py:77:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
btax/tests/test_params_have_effect.py:70: in tst_each_param_has_effect
    tst_once(fast_or_slow, **user_mods)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

fast_or_slow = 'slow'
user_params = {'btax_depr_25yr_exp': 0.0, 'btax_depr_25yr_tax_Switch': True}
tables = {'asset_coc': {'baseline': [['Cost of capital, typically financed corporate investment', 'Cost of capital, typically f...s', 0.28097331634753836, 0.21472645757598893, 0.3549908552857865, 0.254366036745859, -0.11382342165460944], ...]}, ...}
has_changed = False, k = 'industry_d'
changed = [['NPV of depreciation deductions, typically financed corporate investment', 'NPV of depreciation deductions, typicall...cept\xa0oil\xa0and\xa0gas', 0.0, 0.0, 0.0, 0.0, 0.0, ...], ['Support\xa0activities\xa0for\xa0mining', 0.0, 0.0, 0.0, 0.0, 0.0, ...], ...]
row = ['Other\xa0services,\xa0except\xa0government', 0.0, 0.0, 0.0, 0.0, 0.0, ...]
item = 0.0, @py_format1 = 'assert False'

    def tst_once(fast_or_slow, **user_params):
        if fast_or_slow == 'slow':
            # actually run the model
            # and look at the "changed" tables
            tables = run_btax_to_json_tables(**user_params)
            has_changed = False
            for k in tables:
                changed = tables[k]['changed']

                for row in changed:
                    for item in row:
                        if isinstance(item, (float, int)) and item:
                            has_changed = True
                            break
                    if has_changed:
                        break
                if has_changed:
                    break
>           assert has_changed
E           assert False
btax/tests/test_params_have_effect.py:26: AssertionError
==================== 1 failed, 38 passed in 688.54 seconds =====================

@PeterDSteinberg can you confirm?

Currently, the way one inputs user defined reforms in B-Tax is with a function call like the following:

start_year = 2016
iit_reform = {
start_year: {
    '_II_rt5': [.3],
    '_II_rt6': [.3],
    '_II_rt7': [0.3],
}, }

run_btax(start_year,iit_reform,btax_betr_pass=0.23, btax_betr_corp=0.25, btax_depr_allyr_exp=1.,
         btax_other_hair=1.)

The iit_reform dictionary is the reform that is sent to the Tax-Calculator. The arguments following this dictionary in the function call are changes to the policy parameters native to B-Tax.

This issue is to discuss whether B-Tax should adopt the approach used by the Tax-Calculator in using a similar dictionary structure to input reform parameters.

I'm not sure I understand all the relevant trade-offs, but I guess we'd at least want to think about:

1. Do we want consistency across models?
2. Is one method or another more concise?
3. Is one method or another easier to understand?

cc @PeterDSteinberg @talumbau @bfgard

B-Tax needs at least one of the following:

1. An option to produced a series of intermediate tables that are useful to testing calculations. These would allow one to check that asset totals are consistent with the underlying data. CBO (2006) has a nice series of tables we might consider (e.g. those with the ratios of assets across industries).
2. A test to confirm that results only change when they ought to. This is a difficult test to implement since it is necessarily manual. Perhaps it is just a series of tables that are differences between the code as run and that which is in OSE/B-Tax:master.

We should use git keywords for expansion of version in the meta.yaml, so that the git archive command properly inserts the version number:

http://git-memo.readthedocs.io/en/latest/git_archive.html

Our calculations for many types of intellectual property (e.g. artistic productions, books, etc.) do not seem correct.

In the short term, we'll exclude these from our calculations (e.g. as CBO (2014) does. But in the longer run, we should find a better solution.

Try to use only files as formatted from their respective sources (e.g. SOI, BEA, Financial Accounts). Currently, we do some reformatting of these files manually since they are difficult to read into a data frame. It would be ideal to be able to drop in new vintages of files without the additional effort.

Create Travis CI test. We know calculations for z, rho, metr, mettr correct. We need to create a pickle file with objects containing these outputs so that we can check future code revisions continue to produce accurate results.

The model currently uses the "old view" of dividend taxes, where dividend taxes do affect the incentives to invest and thus enter into the METTR. There are differences of opinion as to whether this is the appropriate assumption or whether the "new view" is more relevant. Some research suggests that some firms' behavior most closely aligns with the old view and others the new view.

Given this, we might allow the user the option to specify what view of dividend taxation she would like to use for her analysis. On the other hand, this is a pretty technical issue, so it might not be an option shown to all users by default.

B-Tax needs to be updated to account for the separation of PT income from ordinary income in TC (via PR #913). The more recent PR #987 now allows this to be done properly.

Add calculations for METRs, etc for land to the final outputs. Requires attributing BEA data on land across industry using SOI data.

The METR Guide needs to be updated to reflect the apportionment of SOI and BEA assets that is done in the code. The Guide is also not complete and does not do a good job with land and inventories in particular.

We can apportion the BEA data to the corresponding NAICS codes using the ratio of depreciable assets in the soi data, except for some of the industries (such as 112, 115, 314, 488, 492). How can we calculate a ratio to apportion the data?

In OpenSourcePolicyCenter/webapp-public Issue #295 @MattHJensen asks:

Which parameters from the TaxBrain input page do you think would be relevant?

Those affecting marginal tax rates on business income, capital gains income, dividend income, and interest income could all be relevant. Perhaps some other fields. But we wouldn't take directly those values entered into TaxBrain, since B-Tax will look only at how the "marginal investor" is affected.

Given the field available from the Tax-Calculator (using the PUF-CPS data), maybe the thing to do is to compute the following:

• tau_businc  = weighted average marginal tax rate on ordinary, non-corpororate business income (weighted by amount of non-corp business income)
  

• tau_div = weighted average marginal tax rate on dividend income (weighted by amount of dividend income received)
  

• tau_int = weighted average of marginal tax rate on interest income (weighted by amount of interest income received)
  

• tau_scg = weighted average of marginal tax rate on short term capital gains (weighted by amount of short term capital gains received)
  

• tau_lcg = weighted average of marginal tax rate on long term capital gains (weighted by amount of long term capital gains received)
  

• tau_xcg = weighted average of marginal tax rate on capital gains held until death (weighted by amount of total capital gains received)
  

• tau_td = weighted average of marginal tax rate on pension distributions (weighted by the amount of pension distributions)
  

• tau_h = weighted average marginal tax rate on mortgage interest and property taxes (weighted by amounts of these deductions)
  

@MattHJensen @feenberg

BEA asset totals include tax-exempt businesses. We should remove such assets from the calculator since these entities face not federal tax.

@PeterDSteinberg , would it make sense (and make things more clear) if we rename "run_btax.py" to "execute.py"?

In addition, I have a preference to rename the the following functions within run_btax:

• run_btax to runner
• run_btax_with_baseline_delta to btax_with_baseline_delta
• run_btax_to_json_tables to btax_to_json_tables

These changes follow the naming conventions used in OG-USA and also free up a script named "run_btax.py" to be the script that where one can input reforms to run locally.

Let me know your thoughts and I'll open a PR with these changes.

The Open Source Macroeconomics Laboratory (OSM Lab) has engaged Teodora Szasz (@DoraSzasz) of the University of Chicago Research Computing Center (RCC) to help us with the development of several interactive visualizations. The first of the visualizations that she will be working on is the bubble plot that we prototyped in the plots/contrib/corp_metr repo. That repo has the initial source code and a thumbnail, which is re-posted below.

This plot shows the distribution of tax rates on investment (METR) for the different asset classes (bubbles) with their weight in dollars (bubble size) for the particular industry classification and within the two broad asset classes (equipment and structures). @PeterDSteinberg helped Dora get what she needed to run the CCC locally on her machine for development. @DoraSzasz will post updates in this repository and in this issue thread for public consumption.

We want:

1. Interactive visualization will appear in addition to tabular output after a run of the cost of capital calculator through https://www.ospc.org/ccc/
2. Include either a button for baseline or reform, or show the baseline and reform bubbles together in the visualization but with different colors
3. Year slider bar as shown above
4. User selected x-axis variable (METTR, METR, cost of capital, depreciation)
5. Drop down menu to allow the user to decide which industries to display in the two asset categories on the y-axis
6. Button that allows the user to select corporate or noncorporate
7. User able to download .png screenshots of any state of the image as well as embed the particular interactive version of it as a widget on their own site or in social media

@jdebacker @MattHJensen

When reading in the partnership data from 12pa03.xls, the data for both all partnerships and those with net profits is not handled properly. In particular, the format_stuff() function that formats the raw partnership data does not handle this sheet with repeated variable names well and loses the data for those with net profits.

We need to fix how these data are read in. Temp fix implemented is to manually create a 12pa03_profit.xls file with the data we want.

The sorting of the output tables is not consistent. This means that the "changes" tables (the deltas between the baseline and reform) are not calculated correctly. This affects B-Tax and carries over to CCC. The issue arises when the reform selects a different depreciation system for a subset of the asset types. The final tables' sorting depends on what comes out of the calc_z.py module and the sorting there depends on how some arrays are appended here.

I think my solution will be to apply a sort to the final table by asset and by industry in calc_final_outputs.py. This should be ok since the assets and industries should remain the same across the baseline and reform. A more robust method might be to rewrite btax.util.diff_two_tables() so that it subtracts rows with the same assets/industry rather than rows with the same numeric index. I'm leaning towards the former sol'n as it's easier for me to implement.

cc @PeterDSteinberg @brittainhard

Anyway to account for Sec 199 deductions in METR calculations?

B-Tax has no option for the user to specify expensing of inventories, such as proposed in the House Plan.

An option should be added to allow one to do with without modifying the source code, but rather through a user input parameter.

There is an inability to compute the version. The problem has something to do with versioneer.py and tagging versions or lack thereof:

In [1]: from btax._version import get_versions

In [2]: get_versions()
Out[2]:
{'dirty': None,
 'error': 'unable to compute version',
 'full-revisionid': None,
 'version': '0+unknown'}

B-Tax's interaction with TaxCalc can allow for different start years, but we don't currently update the default business tax parameters to reflect different start years.

We should update the default parameter json to capture the changes in tax parameters over time under current law (e.g. the phase out of bonus depreciation).

@MattHJensen - do we want users to be able to go back in time - or just choose a start year from 2016 forward?

@PeterDSteinberg - what would be the best way to add these defaults to the json file? Do I just enter a list for the default parameters where there is a scalar now?

B-Tax currently calculates the net present value of depreciation deduction under economic depreciation incorrectly. The equation used in calc_z.py is for a discrete time model, which is inconsistent with the continuous time model from which the cost of capital is derived.

The NPV of economic depreciation should be z=delta/(delta+r-inflation rate).

Thanks to Alan Viard for pointing this out.

The methodology outlined in the METR_Guide missed this footnote in the IRS spreadsheets:

[1] Total income (loss) minus total deductions available for allocation does not equal income (loss) allocated to partners by type of partner because not all partnerships report their allocations.

The methodology to allocation assets across type of partners needs to be updated to reflect this. Our current methodology relied on these items adding up and thus has thrown off our total amount of assets attributed to different tax entity types.

The BEA data we use come from 2013. Our SOI data are largely from 2012. This issue is to update those datasources to 2013, which are now available.

• Non-farm sole props
• Partnerships
• S Corps
• C Corps

The B-Tax scripts could benefit from more inline documentation.