Adapt evaluate_planner_objective.m to higher order and perfect foresight

Supersedes #564 (closed) and is related to #1678 (closed) See also https://forum.dynare.org/t/evaluate-planner-objective-in-non-linear-model/15492

Remaining:

• fixing or documenting the regression in behavior introduced in e880d1bc. In contrast to previous behavior histval will be ignored. planner_objective_value now returns conditional and unconditional welfare instead of welfare for different values of the Lagrange multiplier. (done in !1923 (merged))
• the question of an interface for setting the initial condition (preprocessor#64 (closed))
• Adding higher order results to evaluate_planner_objective
• Compute unconditional welfare at order>2
• Documenting the recent changes

added enhancement optimal policy labels

mentioned in issue #564 (closed)

changed title from Adapt evaluate_planner_objective.m to higher order to Adapt evaluate_planner_objective.m to higher order and perfect foresight

changed the description

assigned to @normann

Here is a memo welfare_2nd_order.pdf that details the calculations of welfare at order 2. I amended evaluate_planner_objective.m accordingly and added two test files optimal_policy/neo_growth.mod and optimal_policy/neo_growth_ramsey.mod. I would need your advice on the way of computing conditional welfare, though:

• Should we take the initial shock as given, or should we take the expectation over it? I detail both specifications in my note. The current implementation of evaluate_planner_objective takes it as given.
• It would be nice to compute the conditional welfare from a different starting point than the non-stochastic steady-state. Where could we specify it?

I still need to do the same for the perfect foresight. Order k approximation of welfare can be carried out recursively using the same logic as in Juillard and Kamenik (2004) "Solving Stochastic Dynamic Equilibrium Models: A k-Order Perturbation Approach". It would be better to intervene directly at the preprocessor to do so, imho.

mentioned in merge request !1828 (merged)

mentioned in commit 9066d31d

mentioned in merge request !1833 (merged)

mentioned in commit ea41f190

Perfect foresight done in !1833 (merged).

mentioned in merge request !1866 (closed)

mentioned in commit 3d27672c

Conditional welfare done in !1866 (closed)

@normann Is the above to-do list accurate and complete?

changed the description

It is indeed. After I have rewritten the dynare++ simulation routine in Fortran, the only remaining to-do item should be the setting of the initial condition

Regarding that, evaluate_planner_objective now calls stoch_simul. Why exactly? Just to retrieve decision rules and theoretical moments? Or to be able to get simulated moments?

To retrieve the decision rules. Theoretical moments are not needed; the conditional welfare is the only one computed for now. The simulated moments will provide the necessary terms to derive the unconditional welfare.