Repository navigation
Independent L_dom·y = q test with y read from the Use table's final demand - #1164
Conversation
…nal demand The domestic L y = q test used y_nab, back-computed as (I - A_dom) q, so it held by construction. derive_y_dom_from_use_final_demand reads y from the Use table's final-demand columns plus industry imports, independent of A and q. The new test is xfail: on the canonical MUT it misses q by $1.6T (286 sectors); on #1161 tables by $78bn, mostly waste disaggregation. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
@jvendries @bl-young @MoLi7 Our simple Ly=q test was still circular where y=y_nab=(I − A_dom)·q . y_nab has to be derived independently for this to be a valid test. |
The test now fails until Make and Use agree on commodity output sector by sector, so it reports the gap instead of hiding it. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The test is known to fail until the waste sectors and 331410 are fixed; keep it xfail so it does not report on every PR. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
bl-young
left a comment
There was a problem hiding this comment.
Looks good to approve. The old domestic L·y = q path was circular (y_nab = (I − A_dom) q), so it only checked the inverse. Reading y = Y @ 1 + Uimp @ 1 from the Use table is the right independent demand, and under the canonical nowcast config derive_Aq_scaled is a no-op so units match. Keeping it eeio_integration + xfail is fine until the stored MUT moves off a166975 and #1165 lands.
Two small nits, neither blocking:
-
Please leave a one-line comment on the domestic branch of
test_compare_output_and_L_ythat it only verifiesLinversion given back-computedy_nab-- the independent check is the new test. Otherwise the circular path stays an easy place to hide table inconsistency again. -
Tighten the new test's
xfailreason: #1162 is already onmain; what still fails on the pinnedv0.5.0_a166975is the pre-rebuild MUT, and after a #1162/#1170 rebuild the leftovers are mostly waste kids (#1165) plus331410/S00402. Citing #1161 as the live cause is a bit stale.
…on (review on #1164) Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
Both nits addressed in ad20d5a:
|
Why
The domestic
L·y = qcheck (test_compare_output_and_L_y, domestic case) usesy_nab.derive_y_nabback-computesy_nabas(I − A_dom) qfrom the sameA_domandqthe test then compares, soL_dom · y_nab = qholds by construction for any tables. It confirms the Leontief inverse is computed correctly, not that the tables are consistent.The change
usa_matrices.derive_y_dom_from_use_final_demand()reads final demand from the Use table only:F05000imports column negative;Uimprow sums).The result is the domestic output taken by final demand, exports included. It never sees
Aorq. Negatives are kept, as in the published tables. The function is uncached and has no consumers other than the test.test_domestic_L_y_from_use_final_demand_equals_qchecksL_dom · y = qunder the canonical config at 1% per sector.Aconstruction adds (scrap correction, negative clipping, waste disaggregation).eeio_integration, so CI does not run it. I ran it locally.What it shows
Sector output is commodity output
q, and the gap isL_dom · y − q($bn).v0.5.0_a166975(2024, before #1161)On the stored tables, the largest gaps are retail and wholesale (
454000−$220bn,424A00+$89bn). This is the margin and tax mismatch #1162 fixes.After #1162, the remaining failures are:
562111−9.4%,562HAZ+41%,562910+25%,562OTH+15%,562212−13%;331410nonferrous smelting, +46%;S00402(used goods), whereqis zero.Waste disaggregation splits each parent sector's output across its children without keeping each child's row identity. This is the same cause as the existing
xfailontest_compare_Uset_y_dom_and_q_usa.The test is
xfailuntil the stored MUT is rebuilt with #1162. Rebuilding it is on hold. Even after the rebuild, the waste sectors will keep it failing, so whether to fix them or exempt them is a separate decision.Checks run locally
black --check,ruff check,mypyclean on both files.--runxfailunder the canonical config. It failed as expected: 286 sectors, the 285 above plusS00402.🤖 Generated with Claude Code