-
Notifications
You must be signed in to change notification settings - Fork 75
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
Support explicit uprating #1095
Comments
@nikhilwoodruff : we already have some tools in here. These tools were hosted by But since you are now around, the cost-benefit analysis may change. @MattiSG @sandcha @maukoquiroga : what do you think ? @bfabre01 @clallemand @pzuldp @lukas-puschnig : if you may have some generic tools you want to include in core too, let us know. |
Thanks @benjello - I like that implementation; looks like the main difference is that seems to be specifically year-oriented, as opposed to matching the intervals of the uprating parameter directly? |
I agree with you @nikhilwoodruff. Feel free to propose something more general. |
@benjello how about the implementation we're currently using here? Here's an example of how it'd work: some_uprated_parameter:
values:
2015-01-01: 1
2016-01-01: 2 # last value
metadata:
uprater: uprating_parameter
uprating_parameter:
values:
2015-01-01: 0.5
2016-01-01: 1
2017-01-01: 2
2018-06-01: 3.5 parameters.some_uprated_parameter("2015-01-01") == 1
parameters.some_uprated_parameter("2016-01-01") == 2
parameters.some_uprated_parameter("2017-01-01") == 6 # == 2 * 2/1
parameters.some_uprated_parameter("2018-01-01") == 6 # not yet hit next uprating value
parameters.some_uprated_parameter("2018-06-01") == 10.5 # == 6 * 3.5/2
parameters.some_uprated_parameter("2020-01-01") == 10.5 |
I do not understand this one ...
I understand your need to enrich the metadata with an updating parameter and I have no objection if we can switch on and of the uprating (ou may want to know if a parameter is not directly defined at some date. But one may also want to be able to modify the parameters with a function to build counterfactual (even in the past) etc. sandcha @maukoquiroga : what do you think ? @bfabre01 @clallemand @pzuldp @lukas-puschnig : again if it is something useful for your use case let us know. |
@benjello @nikhilwoodruff we do use uprating as well, using the Indeed, modifying the yaml file seems like a little inconvenient ; there are lots of parameters (at least in #france-system), and the uprating is really based on very few series (basically the predicted inflation rate, and the predicted growth rate of wages). And since we try to limit the parameters to "law only", I think we prefer to modify the T&B by applying functions to it? (and call on separate files, one with uprating parameter series, and possibly another one with uprating parameter-parameters dictionaries ?) Also because it allows more flexibility in changing the series of the uprating parameters (may want to look at the effect of revisions or prediction errors in said uprating parameters ?) just a quick description of our use case (evaluating a law), just in case :
|
To clarify, in openfisca-uk we don't have separate uprating factors for each variable, we assign variables one of a handful of uprating factors. I think @nikhilwoodruff just showed it paired that way as a simple illustration. For example, many of the features are uprated by the consumer price index, which we store here and which is called with the openfisca-tools decorator like this: @uprated(by="CPI")
class housing_costs(Variable): |
Many countries have some kind of uprating policy for legislative parameters. For example, in the UK, the government has described its approach to the Child Benefit as to uprate in line with inflation. It's useful for microsimulation models to be able to forecast future policy years based on the government's policy intentions: instead of manually adding these future planned upratings, it'd be much cleaner and more easily referencable for OpenFisca to do it automatically, e.g. by specifying a metadata attribute for the uprating parameter. We've implemented this in our OpenFisca-Tools package, but I wonder if this could benefit Core.
@benjello @MattiSG I know this differs from the legislative-only approach, as these are government intentions rather than bills. But would it still be relevant to Core?
The text was updated successfully, but these errors were encountered: