Support explicit uprating

[nikhilwoodruff]

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?

[benjello]

@nikhilwoodruff : we already have some tools in here. Let me know what fits your use-case.

These tools were hosted by openfisca-survey-manager because they were not identified as crucial for openfisca-core at the time of their creation to be worth the maintenance burden.

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.

[nikhilwoodruff]

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?

[benjello]

I agree with you @nikhilwoodruff. Feel free to propose something more general.

[nikhilwoodruff]

@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

[benjello]

I do not understand this one ...

parameters.some_uprated_parameter("2017-01-01") == 6 # == 2 * 2/1

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. And it could be more convenient not to have to modify the YAML file to be able o do that.

sandcha @maukoquiroga : what do you think ?

@bfabre01 @clallemand @pzuldp @lukas-puschnig : again if it is something useful for your use case let us know.

[pzuldp]

@benjello @nikhilwoodruff we do use uprating as well, using the inflate_parameter function in openfisca-survey-manager. It is indeed year-base but that corresponds to our use cases (I can't think of an example with non-yearly uprating, but of course, that's just us). Recently I have been thinking of working on the inflate_parameter function to make it accept a series of parameters rather than a single one, so that it can uprate over a few years with different uprating values for each year (because the current state forced us into using loops). Haven't had time to implement it though.

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 :

• we create two T&B systems,
• system A starts from the "actual" system, and if needed uprates the parameters according to the law (this typically happens when the law is proposed and not passed as you describe), either a bunch of parameters with an uprating value, or some manually added/modified values
• system B starts from the system, as of a date in the past (say, one period prior to the law taking effect), and then uprates according to "normal course" uprating rates. This happens for proposed laws, but also past laws (in which case, system A is just the actual system as of the date of the law taking effect).
• comparing A and B on a given set of data highlights the effect of all that's been changed in the T&B between the "asof" date and the date of the law taking effect.

[MaxGhenis]

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):