dynare issueshttps://git.dynare.org/Dynare/dynare/issues2019-06-19T15:38:18Zhttps://git.dynare.org/Dynare/dynare/issues/437Add verbatim option to preprocessor2019-06-19T15:38:18ZJohannes Pfeifer Add verbatim option to preprocessorSometimes one would like to use a keyword detected by the preprocessor in a Matlab command, but the parsing detects this as invalid syntax. If possible, we should add something like a verbatim command to the preprocessor that adds the content without changing it to the m-file.
For example
```
verbatim(cellstr={'eps_a';'eps_b'};)
```
would write the content to the m-file without leading to an error as it currently does if `eps_a` is declared in `var_exo`
Sometimes one would like to use a keyword detected by the preprocessor in a Matlab command, but the parsing detects this as invalid syntax. If possible, we should add something like a verbatim command to the preprocessor that adds the content without changing it to the m-file.
For example
```
verbatim(cellstr={'eps_a';'eps_b'};)
```
would write the content to the m-file without leading to an error as it currently does if `eps_a` is declared in `var_exo`
4.4Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/issues/438investigate problem deleting files with ms-sbvar on windows 72019-06-19T15:38:18ZHoutan Bastaniinvestigate problem deleting files with ms-sbvar on windows 7This is about the problem we discussed with ms_estimation under Windows 7, Matlab 7.8.0 (R2009a). In a nutshell, if msvar is run more than once in a single Matlab session, the init files created on the first run cannot subsequently be deleted. This is a problem as when the init files are not deleted, changes to the model made in the mod file are not reflected in the dynare run. Matlab does not believe that it has any files open – type fopen(‘all’) to check – but windows thinks that Matlab does in fact have these files open. A guess is that the C code may not have fflush()ed the write buffer to the files before closing.
Thanks for your help.
- Roland
To replicate the problem:
· Starting from a clean directory with only RM_test.mod and data_SwitchingFed11_demeaned.dat, run dynare. Should be successful.
· Run dynare a second time. The log file output I get is pasted below. Windows cannot delete “init_RM_test.dat” and other files because they are said to be in use by Matlab.
(email 28 June 2013 12:00:08 PM GMT+02:00)
This is about the problem we discussed with ms_estimation under Windows 7, Matlab 7.8.0 (R2009a). In a nutshell, if msvar is run more than once in a single Matlab session, the init files created on the first run cannot subsequently be deleted. This is a problem as when the init files are not deleted, changes to the model made in the mod file are not reflected in the dynare run. Matlab does not believe that it has any files open – type fopen(‘all’) to check – but windows thinks that Matlab does in fact have these files open. A guess is that the C code may not have fflush()ed the write buffer to the files before closing.
Thanks for your help.
- Roland
To replicate the problem:
· Starting from a clean directory with only RM_test.mod and data_SwitchingFed11_demeaned.dat, run dynare. Should be successful.
· Run dynare a second time. The log file output I get is pasted below. Windows cannot delete “init_RM_test.dat” and other files because they are said to be in use by Matlab.
(email 28 June 2013 12:00:08 PM GMT+02:00)
4.5Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/issues/448Relax check for varobs statement with measurement error.2019-06-19T15:38:18ZJohannes Pfeifer Relax check for varobs statement with measurement error.The following mod-file leads to a preprocessor error of
`ERROR: test_ME_shocks.mod: line 18, cols 1-16: shocks: standard error can only be specified for exogenous or observed endogenous variables`
```
var c, k;
varexo e;
model;
c=0.5*c(+1)+e;
k = 0.9*k(-1);
end;
shocks;
var e; stderr 0.009;
var k; stderr 1;
end;
varobs k;
stoch_simul(periods=500);
```
The reason is that the `varobs` statement comes after the `shocks` block. Moving it before the `shocks` makes the file run. We might want to relax this restriction on the positioning for the check.
The following mod-file leads to a preprocessor error of
`ERROR: test_ME_shocks.mod: line 18, cols 1-16: shocks: standard error can only be specified for exogenous or observed endogenous variables`
```
var c, k;
varexo e;
model;
c=0.5*c(+1)+e;
k = 0.9*k(-1);
end;
shocks;
var e; stderr 0.009;
var k; stderr 1;
end;
varobs k;
stoch_simul(periods=500);
```
The reason is that the `varobs` statement comes after the `shocks` block. Moving it before the `shocks` makes the file run. We might want to relax this restriction on the positioning for the check.
4.4Sébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/issues/446ms-sbvar/test_ms_variances.mod fails under Octave with MatIO 1.52019-06-19T15:38:18ZSébastien Villemotms-sbvar/test_ms_variances.mod fails under Octave with MatIO 1.5Here is the error message:
```
WHILE RUNNING MODFILE: ms-sbvar/test_ms_variances
MSG: load: reading matrix data for 'A0'
IN FILE: /home/sebastien/dynare/unstable/tests/../matlab//ms-sbvar/set_ms_estimation_file.m
IN FUNCTION: set_ms_estimation_file
ON LINE and COLUMN: 49 and 12
```
Note that the problem does not occur with MatIO 1.3.
Here is the error message:
```
WHILE RUNNING MODFILE: ms-sbvar/test_ms_variances
MSG: load: reading matrix data for 'A0'
IN FILE: /home/sebastien/dynare/unstable/tests/../matlab//ms-sbvar/set_ms_estimation_file.m
IN FUNCTION: set_ms_estimation_file
ON LINE and COLUMN: 49 and 12
```
Note that the problem does not occur with MatIO 1.3.
4.4Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/issues/461dynare++ doesn't compile with bison >= 2.72019-06-19T15:38:16ZMichelJuillarddynare++ doesn't compile with bison >= 2.7The functions xx_parse() are now declared int in csv_tab.hh formula_tab.hh and matrix_tab.hh, generated by bison, but declared void in csv_parser.cpp, formula_parser.cpp, matrix_parser.cpp
The functions xx_parse() are now declared int in csv_tab.hh formula_tab.hh and matrix_tab.hh, generated by bison, but declared void in csv_parser.cpp, formula_parser.cpp, matrix_parser.cpp
4.4https://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 Villemot