dynare issueshttps://git.dynare.org/Dynare/dynare/issues2019-06-19T15:38:16Zhttps://git.dynare.org/Dynare/dynare/issues/469Prevent estimating parameters used inside shocks-block2019-06-19T15:38:16ZJohannes Pfeifer Prevent estimating parameters used inside shocks-blockI would classify the following behavior as a bug. `stoch_simul` allows using parameters to set variances inside of the `shocks` block. However, `estimation` completely ignores the updating of such a parameter if it is estimated as the covariance matrix is not updated. As can be seen in the mode_check plots of the attached modification of fs2000.mod, estimating sig_e_a results in the likelihood kernel being flat. Only the prior provides curvature. We should disallow such behavior as people should use the `stderr e_a` version.
```
var m P c e W R k d n l gy_obs gp_obs y dA;
varexo e_a e_m;
parameters alp bet gam mst rho psi del sig_e_a;
alp = 0.33;
bet = 0.99;
gam = 0.003;
mst = 1.011;
rho = 0.7;
psi = 0.787;
del = 0.02;
sig_e_a=0.014;
model;
dA = exp(gam+e_a);
log(m) = (1-rho)*log(mst) + rho*log(m(-1))+e_m;
-P/(c(+1)*P(+1)*m)+bet*P(+1)*(alp*exp(-alp*(gam+log(e(+1))))*k^(alp-1)*n(+1)^(1-alp)+(1-del)*exp(-(gam+log(e(+1)))))/(c(+2)*P(+2)*m(+1))=0;
W = l/n;
-(psi/(1-psi))*(c*P/(1-n))+l/n = 0;
R = P*(1-alp)*exp(-alp*(gam+e_a))*k(-1)^alp*n^(-alp)/W;
1/(c*P)-bet*P*(1-alp)*exp(-alp*(gam+e_a))*k(-1)^alp*n^(1-alp)/(m*l*c(+1)*P(+1)) = 0;
c+k = exp(-alp*(gam+e_a))*k(-1)^alp*n^(1-alp)+(1-del)*exp(-(gam+e_a))*k(-1);
P*c = m;
m-1+d = l;
e = exp(e_a);
y = k(-1)^alp*n^(1-alp)*exp(-alp*(gam+e_a));
gy_obs = dA*y/y(-1);
gp_obs = (P/P(-1))*m(-1)/dA;
end;
initval;
k = 6;
m = mst;
P = 2.25;
c = 0.45;
e = 1;
W = 4;
R = 1.02;
d = 0.85;
n = 0.19;
l = 0.86;
y = 0.6;
gy_obs = exp(gam);
gp_obs = exp(-gam);
dA = exp(gam);
end;
shocks;
var e_a; stderr sig_e_a;
var e_m; stderr 0.005;
end;
steady;
check;
estimated_params;
del, beta_pdf, 0.01, 0.005;
sig_e_a, inv_gamma_pdf, 0.035449, inf;
end;
varobs gp_obs gy_obs;
estimation(order=1,bayesian_irf,irf_shocks=(e_m),datafile=fsdat_simul,mode_check, nobs=192, loglinear, mh_replic=2000, mh_nblocks=2, mh_jscale=0.8);
```
I would classify the following behavior as a bug. `stoch_simul` allows using parameters to set variances inside of the `shocks` block. However, `estimation` completely ignores the updating of such a parameter if it is estimated as the covariance matrix is not updated. As can be seen in the mode_check plots of the attached modification of fs2000.mod, estimating sig_e_a results in the likelihood kernel being flat. Only the prior provides curvature. We should disallow such behavior as people should use the `stderr e_a` version.
```
var m P c e W R k d n l gy_obs gp_obs y dA;
varexo e_a e_m;
parameters alp bet gam mst rho psi del sig_e_a;
alp = 0.33;
bet = 0.99;
gam = 0.003;
mst = 1.011;
rho = 0.7;
psi = 0.787;
del = 0.02;
sig_e_a=0.014;
model;
dA = exp(gam+e_a);
log(m) = (1-rho)*log(mst) + rho*log(m(-1))+e_m;
-P/(c(+1)*P(+1)*m)+bet*P(+1)*(alp*exp(-alp*(gam+log(e(+1))))*k^(alp-1)*n(+1)^(1-alp)+(1-del)*exp(-(gam+log(e(+1)))))/(c(+2)*P(+2)*m(+1))=0;
W = l/n;
-(psi/(1-psi))*(c*P/(1-n))+l/n = 0;
R = P*(1-alp)*exp(-alp*(gam+e_a))*k(-1)^alp*n^(-alp)/W;
1/(c*P)-bet*P*(1-alp)*exp(-alp*(gam+e_a))*k(-1)^alp*n^(1-alp)/(m*l*c(+1)*P(+1)) = 0;
c+k = exp(-alp*(gam+e_a))*k(-1)^alp*n^(1-alp)+(1-del)*exp(-(gam+e_a))*k(-1);
P*c = m;
m-1+d = l;
e = exp(e_a);
y = k(-1)^alp*n^(1-alp)*exp(-alp*(gam+e_a));
gy_obs = dA*y/y(-1);
gp_obs = (P/P(-1))*m(-1)/dA;
end;
initval;
k = 6;
m = mst;
P = 2.25;
c = 0.45;
e = 1;
W = 4;
R = 1.02;
d = 0.85;
n = 0.19;
l = 0.86;
y = 0.6;
gy_obs = exp(gam);
gp_obs = exp(-gam);
dA = exp(gam);
end;
shocks;
var e_a; stderr sig_e_a;
var e_m; stderr 0.005;
end;
steady;
check;
estimated_params;
del, beta_pdf, 0.01, 0.005;
sig_e_a, inv_gamma_pdf, 0.035449, inf;
end;
varobs gp_obs gy_obs;
estimation(order=1,bayesian_irf,irf_shocks=(e_m),datafile=fsdat_simul,mode_check, nobs=192, loglinear, mh_replic=2000, mh_nblocks=2, mh_jscale=0.8);
```
4.4Sébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/issues/476Fix preprocessor bug related to estimated_params_init2019-06-19T15:38:16ZJohannes Pfeifer Fix preprocessor bug related to estimated_params_initThe file
```
var m P c e W R k d n l gy_obs gp_obs y dA;
varexo e_a e_m;
parameters alp bet gam mst rho psi del;
alp = 0.33;
bet = 0.99;
gam = 0.003;
mst = 1.011;
rho = 0.7;
psi = 0.787;
del = 0.02;
model;
dA = exp(gam+e_a);
log(m) = (1-rho)*log(mst) + rho*log(m(-1))+e_m;
-P/(c(+1)*P(+1)*m)+bet*P(+1)*(alp*exp(-alp*(gam+log(e(+1))))*k^(alp-1)*n(+1)^(1-alp)+(1-del)*exp(-(gam+log(e(+1)))))/(c(+2)*P(+2)*m(+1))=0;
W = l/n;
-(psi/(1-psi))*(c*P/(1-n))+l/n = 0;
R = P*(1-alp)*exp(-alp*(gam+e_a))*k(-1)^alp*n^(-alp)/W;
1/(c*P)-bet*P*(1-alp)*exp(-alp*(gam+e_a))*k(-1)^alp*n^(1-alp)/(m*l*c(+1)*P(+1)) = 0;
c+k = exp(-alp*(gam+e_a))*k(-1)^alp*n^(1-alp)+(1-del)*exp(-(gam+e_a))*k(-1);
P*c = m;
m-1+d = l;
e = exp(e_a);
y = k(-1)^alp*n^(1-alp)*exp(-alp*(gam+e_a));
gy_obs = dA*y/y(-1);
gp_obs = (P/P(-1))*m(-1)/dA;
end;
initval;
k = 6;
m = mst;
P = 2.25;
c = 0.45;
e = 1;
W = 4;
R = 1.02;
d = 0.85;
n = 0.19;
l = 0.86;
y = 0.6;
gy_obs = exp(gam);
gp_obs = exp(-gam);
dA = exp(gam);
end;
shocks;
var e_a; stderr 0.014;
var e_m; stderr 0.005;
end;
steady;
check;
estimated_params;
alp, beta_pdf, 0.356, 0.02;
bet, beta_pdf, 0.993, 0.002;
gam, normal_pdf, 0.0085, 0.003;
mst, normal_pdf, 1.0002, 0.007;
rho,2, normal_pdf, 0.129, 0.223;
psi, beta_pdf, 0.65, 0.05;
del, beta_pdf, 0.01, 0.005;
stderr e_a, inv_gamma_pdf, 0.035449, inf;
stderr e_m, inv_gamma_pdf, 0.008862, inf;
corr e_a, e_m, normal_pdf, 0, 0.007;
stderr gp_obs, inv_gamma_pdf, 0.008862, inf;
corr gp_obs, gy_obs, normal_pdf, 0, 0.007;
end;
varobs gp_obs gy_obs;
estimated_params_init;
stderr e_a, 0.014000;
stderr e_m, 0.005000;
stderr gp_obs, 0.000000;
corr e_a, e_m, 0.000000;
corr gp_obs, gy_obs, 0.000000;
alp, 0.330000;
bet, 0.990000;
gam, 0.003000;
mst, 1.011000;
rho, 0.700000;
psi, 0.787000;
del, 0.020000;
end;
estimation(order=1, datafile=fsdat_simul, nobs=192, loglinear, mh_replic=2000, mh_nblocks=2, mh_jscale=0.8,prior_trunc=0);
```
creates matlab code
```
tmp1 = find((estim_params_.corrx(:,1)==1)) & (estim_params_.corrx(:,2)==2);
tmp1 = find((estim_params_.corrn(:,1)==12)) & (estim_params_.corrn(:,2)==11;
```
Somehow the brackets are incorrect and should be
```
tmp1 = find((estim_params_.corrx(:,1)==1) & (estim_params_.corrx(:,2)==2));
tmp1 = find((estim_params_.corrn(:,1)==12) & (estim_params_.corrn(:,2)==11));
```
The file
```
var m P c e W R k d n l gy_obs gp_obs y dA;
varexo e_a e_m;
parameters alp bet gam mst rho psi del;
alp = 0.33;
bet = 0.99;
gam = 0.003;
mst = 1.011;
rho = 0.7;
psi = 0.787;
del = 0.02;
model;
dA = exp(gam+e_a);
log(m) = (1-rho)*log(mst) + rho*log(m(-1))+e_m;
-P/(c(+1)*P(+1)*m)+bet*P(+1)*(alp*exp(-alp*(gam+log(e(+1))))*k^(alp-1)*n(+1)^(1-alp)+(1-del)*exp(-(gam+log(e(+1)))))/(c(+2)*P(+2)*m(+1))=0;
W = l/n;
-(psi/(1-psi))*(c*P/(1-n))+l/n = 0;
R = P*(1-alp)*exp(-alp*(gam+e_a))*k(-1)^alp*n^(-alp)/W;
1/(c*P)-bet*P*(1-alp)*exp(-alp*(gam+e_a))*k(-1)^alp*n^(1-alp)/(m*l*c(+1)*P(+1)) = 0;
c+k = exp(-alp*(gam+e_a))*k(-1)^alp*n^(1-alp)+(1-del)*exp(-(gam+e_a))*k(-1);
P*c = m;
m-1+d = l;
e = exp(e_a);
y = k(-1)^alp*n^(1-alp)*exp(-alp*(gam+e_a));
gy_obs = dA*y/y(-1);
gp_obs = (P/P(-1))*m(-1)/dA;
end;
initval;
k = 6;
m = mst;
P = 2.25;
c = 0.45;
e = 1;
W = 4;
R = 1.02;
d = 0.85;
n = 0.19;
l = 0.86;
y = 0.6;
gy_obs = exp(gam);
gp_obs = exp(-gam);
dA = exp(gam);
end;
shocks;
var e_a; stderr 0.014;
var e_m; stderr 0.005;
end;
steady;
check;
estimated_params;
alp, beta_pdf, 0.356, 0.02;
bet, beta_pdf, 0.993, 0.002;
gam, normal_pdf, 0.0085, 0.003;
mst, normal_pdf, 1.0002, 0.007;
rho,2, normal_pdf, 0.129, 0.223;
psi, beta_pdf, 0.65, 0.05;
del, beta_pdf, 0.01, 0.005;
stderr e_a, inv_gamma_pdf, 0.035449, inf;
stderr e_m, inv_gamma_pdf, 0.008862, inf;
corr e_a, e_m, normal_pdf, 0, 0.007;
stderr gp_obs, inv_gamma_pdf, 0.008862, inf;
corr gp_obs, gy_obs, normal_pdf, 0, 0.007;
end;
varobs gp_obs gy_obs;
estimated_params_init;
stderr e_a, 0.014000;
stderr e_m, 0.005000;
stderr gp_obs, 0.000000;
corr e_a, e_m, 0.000000;
corr gp_obs, gy_obs, 0.000000;
alp, 0.330000;
bet, 0.990000;
gam, 0.003000;
mst, 1.011000;
rho, 0.700000;
psi, 0.787000;
del, 0.020000;
end;
estimation(order=1, datafile=fsdat_simul, nobs=192, loglinear, mh_replic=2000, mh_nblocks=2, mh_jscale=0.8,prior_trunc=0);
```
creates matlab code
```
tmp1 = find((estim_params_.corrx(:,1)==1)) & (estim_params_.corrx(:,2)==2);
tmp1 = find((estim_params_.corrn(:,1)==12)) & (estim_params_.corrn(:,2)==11;
```
Somehow the brackets are incorrect and should be
```
tmp1 = find((estim_params_.corrx(:,1)==1) & (estim_params_.corrx(:,2)==2));
tmp1 = find((estim_params_.corrn(:,1)==12) & (estim_params_.corrn(:,2)==11));
```
Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/issues/477use of tags in write_latex_dynamic_model2019-06-19T15:38:16ZMarco Rattouse of tags in write_latex_dynamic_modelwould it be possible to add tag info in the write_latex_dynamic_model, e.g. by inserting a simple text line with tags info before each equation?
would it be possible to add tag info in the write_latex_dynamic_model, e.g. by inserting a simple text line with tags info before each equation?
4.5Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/issues/478extend tags to definitions2019-06-19T15:38:16ZMarco Rattoextend tags to definitionsWould it be possible to add new tags for parameters, exo and endogenous variables?
Something similar to the $latex-name$ e.g.
var
C $c$ [name = 'private consumption']
...
end;
varexo
e $\varepsilon$ [name='technology shock']
...
end;
parameters
sigma $\sigma$ [name='elasticity of substitution']
...
end;
Would it be possible to add new tags for parameters, exo and endogenous variables?
Something similar to the $latex-name$ e.g.
var
C $c$ [name = 'private consumption']
...
end;
varexo
e $\varepsilon$ [name='technology shock']
...
end;
parameters
sigma $\sigma$ [name='elasticity of substitution']
...
end;
4.4Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/issues/479Fix repmat syntax for R2013b2019-06-19T15:38:16ZHoutan BastaniFix repmat syntax for R2013bRepmat syntax has changed in numerous ways. See the table in the Mathematics section under "Functionality being removed or changed" on this page: http://www.mathworks.fr/fr/help/matlab/release-notes.html
Repmat syntax has changed in numerous ways. See the table in the Mathematics section under "Functionality being removed or changed" on this page: http://www.mathworks.fr/fr/help/matlab/release-notes.html
https://git.dynare.org/Dynare/dynare/issues/487Onlymacro preprocessor option seems to be broken2019-06-19T15:38:16ZJohannes Pfeifer Onlymacro preprocessor option seems to be brokenSee http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=5030
See http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=5030
4.4Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/issues/488dynDate substitution.2019-06-19T15:38:16ZStéphane Adjemianstepan@dynare.orgdynDate substitution.Users should not use dynDate or dynDates objects in a mod file (at least for basic usage: extraction of sub-samples or observations). For instance, one should be able to define a range as follows:
```
r = 1990Q1:2012Q3 ;
```
in the mod file, and use `r` to define a subsample from a dynSeries object. Obviously, such a statement, interpreted as a matlab command by the preprocessor, would produce an error message in matlab. We need to convert occurences of dates by explicit calls to the dynDate constructor. For instance the previous statement should be replaced by
```
r = dynDate('1990Q1'):dynDate('2012Q3') ;
```
It is easy to find all the dates in a mod file a using regular expression of the form
```
[1-9][0-9]+([YyAa]|[Qq][1-4]|[Mm]([1-9]|[1][1-2])|[Ww]([1-9]|[1-4][0-9]|[5][1-2]))
```
The tricky part is that we do not want to replace all the occurences of dates: we do not want to replace dates written in dynare commands (`set_time` and `data`), in commented lines or blocks, in strings.
The matlab routine available [here](https://gist.github.com/stepan-a/6780885) does these substitutions (there is also an example [here](https://gist.github.com/stepan-a/6781075)). It would be faster and more elegant if the translation was done in the preprocessor (after the macroprocessing because dates can be defined using the macro language).
Users should not use dynDate or dynDates objects in a mod file (at least for basic usage: extraction of sub-samples or observations). For instance, one should be able to define a range as follows:
```
r = 1990Q1:2012Q3 ;
```
in the mod file, and use `r` to define a subsample from a dynSeries object. Obviously, such a statement, interpreted as a matlab command by the preprocessor, would produce an error message in matlab. We need to convert occurences of dates by explicit calls to the dynDate constructor. For instance the previous statement should be replaced by
```
r = dynDate('1990Q1'):dynDate('2012Q3') ;
```
It is easy to find all the dates in a mod file a using regular expression of the form
```
[1-9][0-9]+([YyAa]|[Qq][1-4]|[Mm]([1-9]|[1][1-2])|[Ww]([1-9]|[1-4][0-9]|[5][1-2]))
```
The tricky part is that we do not want to replace all the occurences of dates: we do not want to replace dates written in dynare commands (`set_time` and `data`), in commented lines or blocks, in strings.
The matlab routine available [here](https://gist.github.com/stepan-a/6780885) does these substitutions (there is also an example [here](https://gist.github.com/stepan-a/6781075)). It would be faster and more elegant if the translation was done in the preprocessor (after the macroprocessing because dates can be defined using the macro language).
4.4Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/issues/493bug in @dynSeries/subsasgn.m2019-06-19T15:38:16ZMichelJuillardbug in @dynSeries/subsasgn.mUpdating a subsample of a time series results in duplication of the variables:
Example:
z = dynSeries((1:5)',dynDate('1990Q1'),'Z');
d = dynDate('1990Q2'):dynDate('1990Q4');
z(d) = z(d) + 10
This is obviously related to merge_dynSeries_objects = 1; at the beginning of subsasgn.m that triggers merge() at the end of the function and which shouldn't happen in this case. I'm not sure how to fix it without breaking something else.
Updating a subsample of a time series results in duplication of the variables:
Example:
z = dynSeries((1:5)',dynDate('1990Q1'),'Z');
d = dynDate('1990Q2'):dynDate('1990Q4');
z(d) = z(d) + 10
This is obviously related to merge_dynSeries_objects = 1; at the beginning of subsasgn.m that triggers merge() at the end of the function and which shouldn't happen in this case. I'm not sure how to fix it without breaking something else.
4.4Stéphane Adjemianstepan@dynare.orgStéphane Adjemianstepan@dynare.orghttps://git.dynare.org/Dynare/dynare/issues/494Check correctness of set_parameters used in dynare_estimation_12019-06-19T15:38:16ZJohannes Pfeifer Check correctness of set_parameters used in dynare_estimation_11. `dynare_estimation_1` contains the lines
```
if ~isempty(estim_params_)
set_parameters(xparam1);
end
```
I was wondering why not `set_all_parameters` is used, which also sets the measurement error. `set_parameters` may have its justification here, but I don't see why.
2. `set_parameters` sets `M_.Sigma_e`, but in contrast to `set_all_parameters` it does not use the correlation information from calibration stored in `M_.Correlation_matrix` and `M_.Correlation_matrix_ME`. This strikes me as wrong and the file thus as buggy.
This relates also to #392
1. `dynare_estimation_1` contains the lines
```
if ~isempty(estim_params_)
set_parameters(xparam1);
end
```
I was wondering why not `set_all_parameters` is used, which also sets the measurement error. `set_parameters` may have its justification here, but I don't see why.
2. `set_parameters` sets `M_.Sigma_e`, but in contrast to `set_all_parameters` it does not use the correlation information from calibration stored in `M_.Correlation_matrix` and `M_.Correlation_matrix_ME`. This strikes me as wrong and the file thus as buggy.
This relates also to #392
4.4https://git.dynare.org/Dynare/dynare/issues/495Remove dynDate class2019-06-19T15:38:16ZStéphane Adjemianstepan@dynare.orgRemove dynDate classWe do not really need to have both `dynDate` and `dynDates` classes. Need to import some of the methods of `dynDate` class into `dynDates` class.
We do not really need to have both `dynDate` and `dynDates` classes. Need to import some of the methods of `dynDate` class into `dynDates` class.
4.4Stéphane Adjemianstepan@dynare.orgStéphane Adjemianstepan@dynare.orghttps://git.dynare.org/Dynare/dynare/issues/496Add plot function for dynSeries objects.2019-06-19T15:38:16ZStéphane Adjemianstepan@dynare.orgAdd plot function for dynSeries objects.4.4https://git.dynare.org/Dynare/dynare/issues/503Check use and precedence of jscale and document it.2019-06-19T15:38:16ZJohannes Pfeifer Check use and precedence of jscale and document it.The use of `bayestopt_.mh_jscale` and `bayestopt_.jscale` as well as `options_.mh_jscale` is confusing an potentially buggy (see also http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=5072). In `dynare_estimation_1` we use
```
mh_scale_fname = [M_.fname '_optimal_mh_scale_parameter.mat'];
if exist(mh_scale_fname)
if options_.mode_compute == 0
tmp = load(mh_scale_fname,'Scale');
bayestopt_.mh_jscale = tmp.Scale;
clear tmp;
else
% remove the file if mode_compute ~= 0
delete('mh_scale_fname')
end
end
```
to read out the `mh_jscale` from a previous run of `mode_compute=6`. But this is after `dynare_estimation_init` where the `mh_jscale` seems to be translated into the `bayestopt_.jscale` actually used in estimation. Thus, it looks as if this statement does nothing.
The use of `bayestopt_.mh_jscale` and `bayestopt_.jscale` as well as `options_.mh_jscale` is confusing an potentially buggy (see also http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=5072). In `dynare_estimation_1` we use
```
mh_scale_fname = [M_.fname '_optimal_mh_scale_parameter.mat'];
if exist(mh_scale_fname)
if options_.mode_compute == 0
tmp = load(mh_scale_fname,'Scale');
bayestopt_.mh_jscale = tmp.Scale;
clear tmp;
else
% remove the file if mode_compute ~= 0
delete('mh_scale_fname')
end
end
```
to read out the `mh_jscale` from a previous run of `mode_compute=6`. But this is after `dynare_estimation_init` where the `mh_jscale` seems to be translated into the `bayestopt_.jscale` actually used in estimation. Thus, it looks as if this statement does nothing.
4.5Johannes Pfeifer Johannes Pfeifer https://git.dynare.org/Dynare/dynare/issues/505ms-sbvar: support flat option2019-06-19T15:38:16ZHoutan Bastanims-sbvar: support flat option4.4Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/issues/504Discuss and document the load_mh_file option2019-06-19T15:38:16ZJohannes Pfeifer Discuss and document the load_mh_file optionThe current behavior of the `load_mh_file`-option with it recomputing the mode, the Hessian, and the scale-factor by default seems counterintuitive. Given the fixed seed, one should get the same results, but there is the risk of them changing between the reloaded chain and the new elements to be added and thus having a chain with difffering proposal densities. We should at least document this behavior and potentially reload the mode-file by default. See also http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=5051
The current behavior of the `load_mh_file`-option with it recomputing the mode, the Hessian, and the scale-factor by default seems counterintuitive. Given the fixed seed, one should get the same results, but there is the risk of them changing between the reloaded chain and the new elements to be added and thus having a chain with difffering proposal densities. We should at least document this behavior and potentially reload the mode-file by default. See also http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=5051
4.5https://git.dynare.org/Dynare/dynare/issues/506Fix check for balanced growth path2019-06-19T15:38:16ZSébastien VillemotFix check for balanced growth pathThe check implemented in the preprocessor for the balanced growth path does not work well for `logtrend_var`.
Fixing it does not seem trivial, at least it requires some thinking. In the meantime, we may disable the check to make GPM work.
The check implemented in the preprocessor for the balanced growth path does not work well for `logtrend_var`.
Fixing it does not seem trivial, at least it requires some thinking. In the meantime, we may disable the check to make GPM work.
4.4Sébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/issues/517Discuss saving of results2019-06-19T15:38:16ZJohannes Pfeifer Discuss saving of resultsBy default, Dynare only saves the first three of the global structures
```
M_ options_ oo_ estim_params_ bayestopt_ dataset_
```
to the harddisk. We might want accomodate the additional new structures that have been added over time as not all required information is stored in M_, oo_, and options_.
By default, Dynare only saves the first three of the global structures
```
M_ options_ oo_ estim_params_ bayestopt_ dataset_
```
to the harddisk. We might want accomodate the additional new structures that have been added over time as not all required information is stored in M_, oo_, and options_.
Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/issues/520Weibull prior distibution2019-06-19T15:38:16ZMichelJuillardWeibull prior distibutionCMR 2013 are using a Weibull prior distribution. I suggest to add it to the list of prior used by Dynare
CMR 2013 are using a Weibull prior distribution. I suggest to add it to the list of prior used by Dynare
4.5Johannes Pfeifer Johannes Pfeifer https://git.dynare.org/Dynare/dynare/issues/519mode_compute consistency check2019-06-19T15:38:16ZMichelJuillardmode_compute consistency checkIn unstable, we have added a check that reports an error if the parameters contained in a previously computed mode don't match the list of currently estimated ones.
Some users (Christiano, Motto, Rostagno, 2013, public code for Risk Shocks, AER) rely on the behavior of version 4.3.2 that didn't perform this check.
I suggest to transform the error in warning and use the prior mean to initialize estimated parameters that are missing in the previously computed mode.
In unstable, we have added a check that reports an error if the parameters contained in a previously computed mode don't match the list of currently estimated ones.
Some users (Christiano, Motto, Rostagno, 2013, public code for Risk Shocks, AER) rely on the behavior of version 4.3.2 that didn't perform this check.
I suggest to transform the error in warning and use the prior mean to initialize estimated parameters that are missing in the previously computed mode.
4.4Stéphane Adjemianstepan@dynare.orgStéphane Adjemianstepan@dynare.orghttps://git.dynare.org/Dynare/dynare/issues/521Check treatment of covariances in DSGE-VAR2019-06-19T15:38:16ZJohannes Pfeifer Check treatment of covariances in DSGE-VARIn the wake of #392, #494, and #511 various issues with parameter updating around covariance matrices have been detected. None of these changes have been ported to `DsgeVarLikelihood` as the file still contains a TODO list in the comments that suggests that bigger changes are required.
In the wake of #392, #494, and #511 various issues with parameter updating around covariance matrices have been detected. None of these changes have been ported to `DsgeVarLikelihood` as the file still contains a TODO list in the comments that suggests that bigger changes are required.
4.5Stéphane Adjemianstepan@dynare.orgStéphane Adjemianstepan@dynare.orghttps://git.dynare.org/Dynare/dynare/issues/522Deal with negative estimated standard deviation2019-06-19T15:38:14ZJohannes Pfeifer Deal with negative estimated standard deviationIn #392 we had the issue that we do not enforce positive standard deviations. I thus proposed 72208b1b7c7075211edde8fd71e363ccf0d01ca4. @stepan-a suggested that optimizers might dislike the resulting cliff at 0 and that negative standard deviations are perfectly equivalent for the likelihood to the positive ones. Unfortunately, I don't see this as they are not always squared for covariance elements.
In any case, if @stepan-a is correct, we still need to adapt the saving and displaying of parameter estimation results to not confuse users with negative numbers.
In #392 we had the issue that we do not enforce positive standard deviations. I thus proposed 72208b1b7c7075211edde8fd71e363ccf0d01ca4. @stepan-a suggested that optimizers might dislike the resulting cliff at 0 and that negative standard deviations are perfectly equivalent for the likelihood to the positive ones. Unfortunately, I don't see this as they are not always squared for covariance elements.
In any case, if @stepan-a is correct, we still need to adapt the saving and displaying of parameter estimation results to not confuse users with negative numbers.