Both growth.json long_names and descriptions appear to need update

[martinholmer]

Both long_name entries seem to be suggesting values should be percents, but that is contradicted in the descriptions. Should the percent text be dropped from the long_names?

The description of the _factor_target parameter seems to be at variance of what is going on in the code. Is the description wrong? Or is the code wrong? Or am I confused because I don't understand what's going on in the Growth class?

@MattHJensen @Amy-Xu @feenberg @andersonfrailey @GoFroggyRun @codykallen @zrisher
@PeterDSteinberg @talumbau

[codykallen]

I agree that the long_name should not say "percent" or "percentage points". I also think these definitions need to be revised to reflect that the growth rates in factor_target are not CBO's real GDP growth rates.

[martinholmer]

@codykallen said:

I agree that the long_name should not say "percent" or "percentage points".
I also think these definitions need to be revised to reflect that the growth rates in factor_target are not CBO's real GDP growth rates.

Guess I don't understand the Growth class.
What are the "growth rates in factor_target" if they aren't "CBO's real GDP growth rates"?

@MattHJensen @Amy-Xu @feenberg @andersonfrailey @GoFroggyRun @codykallen @zrisher
@PeterDSteinberg @talumbau

[codykallen]

@martinholmer said:

What are the "growth rates in factor_target" if they aren't "CBO's real GDP growth rates"?

I don't know. The growth rates in factor_target are not the CBO growth rates in any of their regular economic and budget projections. Moreover, the growth rates in factor_target for 2013, 2014 and 2015 are not the real growth rates that actually occurred for those years.

Here are the growth rates for each year according to factor_target and to the BEA for 2013-2015 and CBO's Jan 2017 projections for 2016-2026:

2013: 0.0247 (0.017),
2014: 0.0115 (0.024),
2015: 0.0162 (0.026),
2016: 0.0096 (0.016),
2017: 0.0196 (0.023),
2018: 0.0176 (0.020),
2019: 0.0133 (0.017),
2020: 0.0126 (0.015),
2021: 0.0159 (0.018),
2022: 0.0165 (0.019),
2023: 0.0169 (0.019),
2024: 0.0169 (0.019),
2025: 0.0170 (0.019),
2026: 0.0168 (0.019)

[martinholmer]

@codykallen, Thanks for the info about growth rates in issue #1159.

@MattHJensen and @Amy-Xu, can you clarify what is going on in the Growth class?

[Amy-Xu]

I have two points:

• The rates should be CBO real GDP growth rates, and Anderson @andersonfrailey was able to replicate.

• By percent, I meant the percentage of last year GDP, measuring the scale of growth this year. The other percentage point refers to percentage point in decimal format. If you have better terms, that's great! Please replace the old ones.

[martinholmer]

@codykallen said:

Here are the growth rates for each year according to factor_target and to the BEA for 2013-2015 and CBO's Jan 2017 projections for 2016-2026:

2013: 0.0247 (0.017),
2014: 0.0115 (0.024),
2015: 0.0162 (0.026),
2016: 0.0096 (0.016),
2017: 0.0196 (0.023),
2018: 0.0176 (0.020),
2019: 0.0133 (0.017),
2020: 0.0126 (0.015),
2021: 0.0159 (0.018),
2022: 0.0165 (0.019),
2023: 0.0169 (0.019),
2024: 0.0169 (0.019),
2025: 0.0170 (0.019),
2026: 0.0168 (0.019)

@codykallen, can you provide a link and page reference to the CBO Jan 2017 projections?

[codykallen]

@martinholmer asked:

can you provide a link and page reference to the CBO Jan 2017 projections?

The projections come from the CBO January 2017 "Budget and Economic Outlook and Updates" on page 88. The Excel files with the projections can be found here under the "10-Year Economic Projections" section. This page also has the projections from previous reports, which also do not match those on factor_target.

[martinholmer]

@Amy-Xu said:

The rates should be CBO real GDP growth rates, and Anderson @andersonfrailey was able to replicate.

@codykallen said:

The projections come from the CBO January 2017 "Budget and Economic Outlook and Updates" on page 88. The Excel files with the projections can be found here under the "10-Year Economic Projections" section. This page also has the projections from previous reports, which also do not match those on factor_target.

So, @andersonfrailey, are the real GDP growth rates in the growth.py file supposed to be the same as the CBO January 2017 real GDP growth rates? If they are not supposed to be the same as those rates, then what CBO real GDP growth rates are they supposed to match?

@MattHJensen

[andersonfrailey]

Since I started working on TaxCalc, real GDP growth rates haven't matched CBO real GDP growth rates. When I was trying to recreate them, I found the real GDP growth rates were determined using AGDPN and ACPIU in Stage 1 factors:

(AGDPNy / AGDPNy-1 - 1) - (ACPIUy/ACPIy-1 -1)

I'm not sure why this has been the case rather than using the growth rates in the CBO economic projections, but @MattHJensen brought this up in issue #1144. I'll be updating the real GDP growth rates in growth.py so they match the CBO's real GDP growth rates from now on and updating documentation so they match in future updates.

@martinholmer @Amy-Xu @codykallen

[martinholmer]

@andersonfrailey said:

Since I started working on TaxCalc, real GDP growth rates haven't matched CBO real GDP growth rates. When I was trying to recreate them, I found the real GDP growth rates were determined using AGDPN and ACPIU in Stage 1 factors:

(AGDPNy / AGDPNy-1 - 1) - (ACPIUy/ACPIy-1 -1)

I'm not sure why this has been the case rather than using the growth rates in the CBO economic projections, but @MattHJensen brought this up in issue #1144. I'll be updating the real GDP growth rates in growth.py so they match the CBO's real GDP growth rates from now on and updating documentation so they match in future updates.

(a) But if the real GDP growth rates are used in the preparation of the StageIfactors.csv values or the Stage3 adjustment-factor values, then you'll have to redo those calculations as well, right?

(b) The formula you describe above is incorrect, which is why the printed CBO rates and the Growth.REAL_GDP_GROWTH_RATES differ by so much. The correct formula is derived as follows:

(1)  R_t = G_t / P_t            : the definition of real GDP in year t
(2)  1+g = R_t / R_t-1        : the definition of the rate of growth g
Substituting (1) into (2) gives (3):
(3)  1+g = ( G_t / P_t ) / ( G_t-1 / P_t-1 )
And (3) simplifies to (4):
(4)  1+g = ( G_t / G_t-1 ) / ( P_t / P_t-1 )

So, as you can see there is no subtraction; the correct formula uses division.

@MattHJensen @Amy-Xu @codykallen

[andersonfrailey]

@martinholmer, with regards to this comment:

(a) But if the real GDP growth rates are used in the preparation of the StageIfactors.csv values or the Stage3 adjustment-factor values, then you'll have to redo those calculations as well, right?

The real GDP growth rates aren't used in preparation of StageIfactors.csv or the stage 3 adjustment factors.

With regards to this:

So, as you can see there is no subtraction; the correct formula uses division.

Right. But looking at the function
def test_default_rates_and_those_implied_by_blowup_factors(puf_1991): in test_records.py, you see that to pass this test the values of Growth.REAL_GDP_GROWTH_RATES come from the formula I posted. Here is a snippet of the code:

    # back out original stage I GDP growth rates from blowup factors
    record.BF.AGDPN[Records.PUF_YEAR] = 1
    for year in range(Records.PUF_YEAR + 1, endyr + 1):
        record.BF.AGDPN[year] = (record.BF.AGDPN[year] *
                                 record.BF.AGDPN[year - 1] *
                                 record.BF.APOPN[year])

    # calculate nominal GDP growth rates from original GDP growth rates
    nominal_rates = np.zeros(nyrs)
    for year in range(syr + 1, endyr):
        irate = policy._inflation_rates[year - syr]
        nominal_rates[year - syr] = (record.BF.AGDPN[year] /
                                     record.BF.AGDPN[year - 1] - 1 - irate)

    # check that nominal_rates are same as default GDP growth rates
    nominal_rates = np.round(nominal_rates, 4)
    assert_array_equal(nominal_rates[1:], Growth.REAL_GDP_GROWTH_RATES[1:-1])

irate is equal to (ACPIU_y / ACPIU_y-1) - 1 where ACPIU is the value seen in StageIfactors.csv, as confirmed by another test in the same function:

    # back out stage I inflation rates from blowup factors
    cpi_u = np.zeros(nyrs)
    for year in range(syr, endyr):
        cpi_u[year - syr] = record.BF.ACPIU[year] - 1

    # check that blowup rates are same as default inflation rates
    cpi_u = np.round(cpi_u, 4)
    assert_array_equal(cpi_u, policy._inflation_rates[:-1])

because at that point record.BF.ACPIU[year] = ACPIU_year / ACPIU_year-1 where again ACPIU is the value in StageIfactors.csv.

So it seems to me that it REAL_GDP_GROWTH_RATES isn't an accurate description of what those numbers actually represent and either the test needs to change or the name should change.

[martinholmer]

@andersonfrailey said:

With regards to this:

So, as you can see there is no subtraction; the correct formula uses division.

Right. But looking at the function
def test_default_rates_and_those_implied_by_blowup_factors(puf_1991): in test_records.py, you see that to pass this test the values of Growth.REAL_GDP_GROWTH_RATES come from the formula I posted. Here is a snippet of the code: ...[snip] ...

Excellent point @andersonfrailey! It is very good that you spotted this problem. I've looked into the history of this test, which was originally located in the test_calculate.py file where it was named test_hard_coded_parameter_consistency(). That test was added as part of pull request #424, which was merged into the master branch on Nov 6, 2015. And that same pull request also added the values of the Growth class REAL_GDP_GROWTH[_RATES] list. Those growth rate values were specified to pass the test, which, as you point out, uses an incorrect formula. So that means the growth rate values are incorrect, which has been the point @codykallen has been making. In other words, if the formula in the test is corrected, the test will fail using the current values in the Growth.REAL_GDP_GROWTH_RATES list. I'll try to fix the formula in the test and see if the Growth.REAL_GDP_GROWTH_RATES values that pass the corrected test are closer to the CBO values. Does this make sense?

[martinholmer]

Pursuing my previously described plan to redo the hard-coded-rates consistency tests (see #1159), I have discovered that pull request #428, which was merged into the master branch on Nov 9, 2015 (just three days after #424 was merged), added Policy.__wgrates and a consistency test for wage growth rates. The values in the added Policy.__wgrates dictionary, which are by default read into the Policy object's _wage_growth_rates list, were specified in #428 to pass that consistency test. So, part of redoing the consistency tests will be to check the validity of the wage-growth-rate consistency test (because if it is not valid, then the values in the Policy.__wgrates dictionary are not valid).

@MattHJensen @andersonfrailey @codykallen

[andersonfrailey]

@martinholmer your plan to re-do the consistency tests makes sense to me.

Part of redoing the consistency tests will be to check the validity of the wage-growth-rate consistency test

I just took a quick look at the the wage growth rate in the CBO economic projections and there are three years where the rates differ by one ten-thousandth, but besides that they all match up.

Year	TC	CBO
2015	0.0477	0.0478
2016	0.0472	0.0472
2017	0.0436	0.0436
2018	0.0407	0.0407
2019	0.0364	0.0363
2020	0.0362	0.0362
2021	0.0386	0.0386
2022	0.0394	0.0393
2023	0.0395	0.0395
2024	0.0394	0.0394
2025	0.0394	0.0394
2026	0.0393	0.0393

I used the August 2016 version of the file rather than January 2017 to stay consistent with which file was used to determine the hard-coded values in Policy__wrates.

[martinholmer]

@andersonfrailey, Thanks for checking the hard-coded Policy.__wgrates values against those in the August 2016 CBO 10-Year Economic Projection. Let me confirm my understanding of what you did in this comparison. Did you use data for aggregate "Wages and Salaries" under the Income heading in the CBO spreadsheet?

[andersonfrailey]

@martinholmer that is correct. Specifically in the calendar year tab.

[martinholmer]

Issue #1159 has been resolved by pull requests #1162, #1164, #1167 and #1171.