Recent changes to resol.m, passing structure M_ as an argument, breaks *_steadystate.m files when they modify the value of a parameter.
Before the modification was sent to the calling program via global M_, but if this variable is now local to the calling program the modification of the parameter is just ignored by the computing chain (until the next top level instruction: stoch_simul, check, estimation , ....).
Dealing with global variables is detrimental to efficiency and can cause, as in this case, hard to see side effects. So, it is a good thing to eliminate global variables from resol.m On the other hand, it is highly desirable to keep backward compatibility with existing *_steadystate.m file, otherwise, we will spend a huge amount of time explaining user why their program don't work anymore or, worst, why it doesn't give the same result as with the previous Dynare version and that the new result is wrong.
In any case, using a steady_state_model block within the *.mod file is superior because handling of variables and parameters indices is much more efficient. Furthermore, almost all desirable syntax is now supported by steady_state_model block, even calling a nonlinear solver for a small set of equations (those still have to be written in a separate *.m file).
I propose the following:
1) change the name of the *.m file created by steady_state_model from <fname>_steadystate.m to <fname>_steadystate1.m 2) send back params as an output argument of <fname>_steadystate2.m (in a second step, we can to the preprocessor the necessary code to recognize whether params has changed or not) 3) when the old <fname>_steadystate.m file is called, add a call to evalin(M_.params) to bring back the global variable. 4) Use options_.steadystate_flag to distinguish when to call <fname>_steadystate.m and <fname>_steadystate2.m. The new function <fname>_steadystate2.m takes precedence. 4) Factorize the evaluation of the steady-state in a separate Matlab function and call this new function when necessary. I have started and shall finish soon. 5) I have also started to write a "Howto compute steady-state" and will accelerate this project. 6) I will discuss with Ferhat the implication for blocks and bytecode
Tell me what you think
Best
Michel
Hi Sebastien
running Dynare 4.2.2 with conditional_forecast(periods =40,parameter_set = posterior_mean,controlled_varexo = (em)) I got error
??? Error using ==> eval Reference to non-existent field 'posterior_mean'.
Error in ==> get_posterior_parameters at 46 xparam(m) = eval(['oo_.posterior_' type '.shocks_std.' name1]);
Error in ==> imcforecast at 57 xparam = get_posterior_parameters('mean');
I.e. when checking oo_ I found only oo_.posterior_mode ans = parameters: [1x1 struct] shocks_std: [1x1 struct]
and no .posterior_mean despite it being specified in the model file
This posterior_mean model specification used to work with 4.2.1 but it looks like recent changes made posterior_mode the only option (I have not tried other options but it works with posterior_mode specified in mod file also) .
2) what is role of constrained_vars in cond. forecasting, how is it chosen or set and why is it set constrained_vars_ = 1; in the <model>.m file?
Best regards George
Hi George,
this bug is fixed in unstable. Please, tell me if it works for you.
Best
Michel
On 10/12/2011 09:50 PM, George wrote:
Hi Sebastien
running Dynare 4.2.2 with conditional_forecast(periods =40,parameter_set = posterior_mean,controlled_varexo = (em)) I got error
??? Error using ==> eval Reference to non-existent field 'posterior_mean'.
Error in ==> get_posterior_parameters at 46 xparam(m) = eval(['oo_.posterior_' type '.shocks_std.' name1]);
Error in ==> imcforecast at 57 xparam = get_posterior_parameters('mean');
I.e. when checking oo_ I found only oo_.posterior_mode ans = parameters: [1x1 struct] shocks_std: [1x1 struct]
and no .posterior_mean despite it being specified in the model file
This posterior_mean model specification used to work with 4.2.1 but it looks like recent changes made posterior_mode the only option (I have not tried other options but it works with posterior_mode specified in mod file also) .
- what is role of constrained_vars in cond. forecasting, how is it
chosen or set and why is it set constrained_vars_ = 1; in the <model>.m file?
Best regards George
Dev mailing list Dev@dynare.org https://www.dynare.org/cgi-bin/mailman/listinfo/dev