pslmodels / cost-of-capital-calculator Goto Github PK
View Code? Open in Web Editor NEWA cost of capital and effective tax rate calculator
Home Page: https://ccc.pslmodels.org
A cost of capital and effective tax rate calculator
Home Page: https://ccc.pslmodels.org
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.
Changing this parameter didn't seem to affect output. Check that it is working properly and fix if necessary.
Add calculations for METRs, etc for inventories to the final outputs. Requires attributing BEA data on inventories across industry using SOI data.
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.
Anyway to account for Sec 199 deductions in METR calculations?
@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.
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?
BEA asset totals include tax-exempt businesses. We should remove such assets from the calculator since these entities face not federal tax.
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.
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?
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
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.
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)
Add calculations for METRs, etc for land to the final outputs. Requires attributing BEA data on land across industry using SOI data.
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.
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.
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?
B-Tax needs at least one of the following:
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.
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 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.
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:
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.
The B-Tax scripts could benefit from more inline documentation.
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.
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.
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.
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.
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 yield much different ratios than was CBO (2007) finds. In particular, CBO finds:
A place to start is in read_bea.py, where these asset types are attributed across industry and tax treatment.
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.
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.
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:
We should use git keywords for expansion of version in the meta.yaml, so that the git archive
command properly inserts the version number:
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.
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.
When setting the depreciation system to economic depreciation for some, but not all, asset classes, the change seems to affect all classes of depreciation.
When switching to ADS depreciation, results are nulls.
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).
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.
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.
Consider updating the BEA_IRS_Crosswalk.csv document to
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.
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:
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.
Looks like a file called visuals_plotly.py
was not added to git. It is imported by run_btax.py
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:
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?
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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.