Skip to content

GitLab

  • Menu
Projects Groups Snippets
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • dynare dynare
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 108
    • Issues 108
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 7
    • Merge requests 7
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • Dynare
  • dynaredynare
  • Issues
  • #1705
Closed
Open
Created Feb 06, 2020 by Johannes Pfeifer@JohannesPfeiferDeveloper

Fix, clean and speed up discretionary_policy routines

As is discretionary_policy_1.m has various issues

  1. At its end, we have
function ys=NondistortionarySteadyState(M_)
if exist([M_.fname,'_steadystate.m'],'file')
    eval(['ys=',M_.fname,'_steadystate.m;'])
else
    ys=zeros(M_.endo_nbr,1);
end

which seems to miss the case of a steady_state_model-block. It's also not clear why we have this in any case. At the end of the function, we write ys based on this input. But throughout the function, like in

[U,Uy,W] = feval([M_.fname,'.objective.static'],zeros(endo_nbr,1),[], M_.params);

we assume the steady state to be 0.

  1. The handling of error codes should be nested into the print_info-framework as opposed to always issuing errors.

  2. The function is very verbatim in terms of providing diagnostics. That is useful in standalone code, but a bottleneck when run in a loop like estimation where we only want to discard infeasible draws without providing diagnostics.

  3. The order of some checks is strange. We do computations on the model before checking e.g. whether the number of instruments is valid. We should be able to do this without computing the Jacobian. Also a check like this should only be done once in the context of estimation and does not belong into the core engine. This suggests a different factorization.

Related to #1173 (closed)

Edited Feb 06, 2020 by Sébastien Villemot
Assignee
Assign to
Time tracking