Support estimation under optimal policy

This should be doable by replacing the call to [T,R,SteadyState,info,Model,DynareOptions,DynareResults] = dynare_resolve(Model,DynareOptions,DynareResults,'restrict'); in dsge_likelihood.m by a call to the respective solution technique with the default being the current one, but also allowing for Ramsey, commitment and OSR, conditional on the estimated parameters.

I believe it is currently possible with Ramsey policy when you use the {{{ramsey_model}}} syntax. The maintained assumption is that the initial Lagrange multiplier were at steady state before the beginning of the sample. This is a conceptual issue while estimating assuming Ramsey policy: one has to take a stand about when did optimal policy start. Estimating under OSR would be extremely costly as Dynare would have to perform numerical optimization for each tentative value of the parameters. I wouldn't implement it. I don't know what you refer to by ¨commitment"

@MichelJuillard I meant discretionary_policy

added new algorithm label

added optimal policy label

removed milestone

assigned to @stepan-a

changed milestone to %4.6

assigned to @sebastien and unassigned @stepan-a

changed milestone to %4.6

@sebastien I am willing to help here. What is the status? ramsey_model already works as far as I can see.

I'm currently looking into how to plug the discretionary policy engine into dsge_likelihood.m, as you explained above.

Thanks for your offer, I'd very much like to accept it, but I don't know how to split this (relatively small) task into subtasks…

@MichelJuillard @stepan-a @JohannesPfeifer As I started working on this, I hit an issue related to the estimation of the discount factor itself.

Suppose for example that we have planner_discount = beta*theta, where beta and theta are deep parameters. Also assume that beta and theta appear in the model block. The preprocessor currently appends a new parameter to M_.params, with name optimal_policy_discount_factor, and calibrates it to the product of the values of beta and theta.

Now suppose that I estimate beta: within the estimation loop, the value of optimal_policy_discount_factor will not be updated as beta moves, hence the result of the estimation will be wrong.

Conceptually, the problem is that optimal_policy_discount_factor is treated as a deep parameter, while in this case it is rather a transformation of the parameters. On the other hand, if optimal_policy_discount_factor was unrelated to the other parameters (calibrated to a constant), then it would make sense to treat it as a deep parameter.

How should we deal with this?

One possibility is to consider that we don’t support the estimation of parameters that appear in the expression defining the discount factor, and enforce that restriction.

Otherwise, we have to implement some mechanism to update the optimal_policy_discount_factor in the estimation loop using the formula given in the planner_discount option (unless this parameter is itself listed in the estimated_params block). Where should that be done? That also implies some not-so-straightforward modifications in the preprocessor.

Note that this problem probably also affects estimation under Ramsey policy, though I did not check.

Would it work to establish to following convention:

if planner_discount is present in ramsey_model or in discretionary_policy, the associated value is used for initialization and the parameter is estimated. optimal_policy_discount_factor can't appear in the model block
if optimal_policy_discount_factor is used as transformation of the parameters in the model block, it is handled as such in estimation

The big question is whether we want to allow users to estimate the optimal_policy_discount_factor when it's a constant. In this case, it truly is a deep parameter and we may want to treat it as such.

But in cases where it's a composite, we could treat it as a model-local variable (or course with a check that it does not contain variables). That would solve all issues. A downside here is that users then cannot easily access the value of the composite parameter. But this is something that has been bothering me for a long time. We could simply have the preprocessor write the formula for the model-local variable into a Matlab string that we could evaluate using a separate function. That would be handy for example in cases where one needs the slope of the NK Phillips Curve. In https://github.com/JohannesPfeifer/DSGE_mod/blob/master/Gali_2015/Gali_2015_chapter_4.mod I had to reconstruct lambda from scratch.

@JohannesPfeifer if I read you correctly our two proposals aren't very different. Correct? The issue that you raise concerns of course all local variables and should be handled as such

@MichelJuillard Indeed. I pointed to a way we could implement your proposal in our current framework.

One question: you wrote "optimal_policy_discount_factor can't appear in the model block". Is that already possible? That feature is not documented at all.

@JohannesPfeifer I don't know. Never tried it. If we don't forbid it explicitly in the parser, I don't see why we couldn't do it.

Support estimation under optimal policy

Designs

Child items ...

Activity