Dynare forums

Hello all,

I have a problem using conditional_forecast command in Dynare 4.2.1. It seems that the dynare interpreter isn´t creating properly the .m file. To be more specific, the conditioning variable 'r' as setted in the mod file is translated to constrained_vars_ = '46' in the m file, where 46 is exactly the order number of 'r' in the variables declaration. Furthermore, when I put two conditioning variables in mod file, the problem remains for both, but the way those variables are written in m file is quite different.

Have anyone had the same problem?

mike


mod file:

Code: Select all

conditional_forecast_paths;
var r;
periods 1:4;
values 0.25;
end;
conditional_forecast(parameter_set = posterior_mean, controlled_varexo =(e_R));

m file:

Code: Select all

constrained_vars_ = [];
constrained_paths_ = zeros(1, 4);
constrained_vars_ = '46';
constrained_paths_(1,1)=0.25;
constrained_paths_(1,2)=0.25;
constrained_paths_(1,3)=0.25;
constrained_paths_(1,4)=0.25;
options_cond_fcst_ = struct();
options_cond_fcst_.parameter_set = 'posterior_mean';
options_cond_fcst_.controlled_varexo=[];
options_cond_fcst_.controlled_varexo = 'e_R';
imcforecast(constrained_paths_, constrained_vars_, options_cond_fcst_);

I am also having problems with this command... I basically copy the example in the user guide, and it does not work.

Hi,

Can you post a complete example MOD file, so that we can reproduce exactly your problem?

Thanks

Hi,
I send a mod file that I have found of Michel Juillard about conditional forecast. I also send the data to run the code.

The problem is the following:

??? Attempted to access idx(1); index out of bounds because numel(idx)=0.

Error in ==> imcforecast at 173
mv(i,idx(i)) = 1;

Error in ==> fs2000_est at 213
imcforecast(constrained_paths_, constrained_vars_, options_cond_fcst_);

Error in ==> dynare at 132
evalin('base',fname) ;

Could you please help me with this?.
Thanks
Carlos J.

I am facing the same problem. Any color on that that could help solve or bypass this issue would be nice.

Daniel

Hi,This mod file runs smoothly on 4.2.2 . The bug (if any) has been solved.
Best, Stéphane.

StephaneAdjemian wrote:Hi,This mod file runs smoothly on 4.2.2 . The bug (if any) has been solved.
Best, Stéphane.

I desagree. The problem presists even in version 4.2.4. The solution that I found to work nicely is to edit the model.m file itself, instead of the .mod file. The contribution above is right when stating the problem lies in the process of translating the correct identification number (order) of the variables to be conditioned from the model.mod file to the model.m file. With some limited effort it is possible to make a list of variables and their corresponding identification number and then modify the .m file accordingly to get the right results.

Regards,

Daniel

I confirm what Stéphane said: this MOD file works with Dynare 4.2.4.

I encourage you to double check your Dynare installation. And if you still have failures, can you report the error message?

Best,

Hi,

I have the same problem (using fs2000.mod ).

Although I condition on gy_obs, the number of the constrained variable in the .m file is 10, which corresponds to the variable l.

The forecast plot shows indeed that it is the variable l to be constrained and not gy_obs.

Best

Gianni

SébastienVillemot wrote:I confirm what Stéphane said: this MOD file works with Dynare 4.2.4.

I encourage you to double check your Dynare installation. And if you still have failures, can you report the error message?

Best,

Thank you for your reply. But I sill maintain my previous assessment: Dynare 4.2.4 still mixes up the variables orders when generating the .m file from the .mod file. It is indeed possible to get the right results, but you have to change the .m file directly (which, quite frankly, is not a big deal). From my experience, the variable order generated by the .mod file is -1 of the correct one. But I am not sure if that is applicable to all cases and examples. There is no error messages related with the procedure itself. The problem is noticeable in two ways: (i) if you check out the generated graphs, you will realize the trajectories pointed out are not the ones you've indicated and (ii) often, the mix up will impose an unfeasible trajectory to certain variable (i.e.: constant interest rate values into, say, FX level), which will press to an error message of indeterminacy.

Regards,

Daniel

Dear Daniel,

I finally pushed a fix for this bug (git# 8dc1b9037d3b0c6988fa1cebc2644aea404982b1). The fix will be in the snapshot version tomorrow or in Dynare 4.3 (to be released next week). Thanks for your input.

Best,
Stéphane.