Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Indexing parameter values, rounding rules #130

Open
jdebacker opened this issue Feb 7, 2022 · 3 comments
Open

Indexing parameter values, rounding rules #130

jdebacker opened this issue Feb 7, 2022 · 3 comments

Comments

@jdebacker
Copy link
Member

Often, when policy parameters are indexed to inflation, they are subject to rounding rules. For example, policy parameters of the US income tax code such as income thresholds defining tax brackets are index to inflation, but, in order to be more clear to taxpayers, are rounded to whole dollar amounts.

Rounding rules like this are often parameter-specific. For example, for some policy parameters rounding may be downward, while for others it's upward. For some, rounding maybe to the nearest $50 increment, for others $1, or $100.

The Tax-Calculator project currently addresses rounding by updating parameter values after the IRS publishes numbers with the rounding rules applied (see the updating process in PR #2633). This is a pretty big maintenance issue for that project. Hardcoding in these values also has other limitations.

One solution is to allow the model parameters to be given indexing rules. Since the Tax-Calculator project uses ParamTools to handle parameter inputs, validation, and extrapolation this Issue is to discuss if this might be possible to do in ParamTools.

I think what one would want is the following:

  • A metadata field in the ParamTools schema that defines what the name of the indexing parameter is (e.g., for Tax-Calculator parameter II_brk1, this could be "CPI".
  • A metadata field in the ParamTools schema that defines what the rounding rule is

E.g. (where this gives indexing to the CPI with rounding upwards to the nearest $1),

    "II_brk1": {
        "title": "Personal income (regular/non-AMT/non-pass-through) tax bracket (upper threshold) 1",
        "description": "Taxable income below this threshold is taxed at tax rate 1.",
        "notes": "",
        "section_1": "Personal Income",
        "section_2": "Regular: Non-AMT, Non-Pass-Through",
        "indexing":{
            "indexable": true,
            "indexed": true,
            "index_parameter": "CPI",
            "rounding":{
                "interval": 1,
                "type": "upwards" 
        }
        "type": "float",
        "value": [
            {
                "year": 2013,
                "MARS": "single",
                "value": 8925.0
            },
     ...

Would this be possible in ParamTools? Potential drawbacks to this approach?

cc @MattHJensen @nikhilwoodruff @MaxGhenis

@nikhilwoodruff
Copy link

This looks like a pretty comprehensive write up @jdebacker, thanks. Only thing I'd add is that I've occasionally seen examples where different marital statuses have different rounding rules: e.g. where single filers round to $100, joint filers round to $50.

@jdebacker
Copy link
Member Author

different marital statuses have different rounding rules: e.g. where single filers round to $100, joint filers round to $50.

Good point. Perhaps for this case (which should actually in the example above), one could have "interval" (and maybe other keys) be a list?

@jdebacker
Copy link
Member Author

jdebacker commented May 23, 2022

A note per further discussion: may want the "index_parameter" (and potentially other indexing rule parameters) to vary by year, e.g., to capture legislative changes to these such as the TCJA.

One idea is to have the "index_parameter" take a string (that is in a set list, e.g., "CPI-U", "Chained CPI-U", "wages") or a dictionary of key value pairs (for custom growth rates by year).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants