dynare issueshttps://git.dynare.org/Dynare/dynare/issues2020-01-24T17:25:41Zhttps://git.dynare.org/Dynare/dynare/issues/1694Identification tests fail for old matlab2020-01-24T17:25:41ZWilli Mutschlerwilli@mutschler.euIdentification tests fail for old matlabSome identification tests fail under MATLAB R2009b, see https://git.dynare.org/Dynare/dynare/-/jobs/12770. Some functions need to be replaced.Some identification tests fail under MATLAB R2009b, see https://git.dynare.org/Dynare/dynare/-/jobs/12770. Some functions need to be replaced.4.6Willi Mutschlerwilli@mutschler.euWilli Mutschlerwilli@mutschler.euhttps://git.dynare.org/Dynare/dynare/issues/1689Clarify licensing information for identification stuff2020-01-24T14:41:20ZSébastien VillemotClarify licensing information for identification stuffSee !1689
The information should be added in the corresponding headers, and in `license.txt`See !1689
The information should be added in the corresponding headers, and in `license.txt`4.6Willi Mutschlerwilli@mutschler.euWilli Mutschlerwilli@mutschler.euhttps://git.dynare.org/Dynare/dynare/issues/1649new plot_shock_decomposition options2019-12-06T15:30:45ZMarco Rattonew plot_shock_decomposition optionsIt would be useful to allow the preprocessor to take the following new options, both for `plot_shock_decomposition` and `initial_condition_decomposition`:
* `diff`: plots the first difference of the requested variable
* `flip`: flip the requested variables with sign change (e.g. useful to flip the concept of an exchange rate or trade balance or deficit/surplus variable without having to define it in model definition)
I have already provisions ready to push.It would be useful to allow the preprocessor to take the following new options, both for `plot_shock_decomposition` and `initial_condition_decomposition`:
* `diff`: plots the first difference of the requested variable
* `flip`: flip the requested variables with sign change (e.g. useful to flip the concept of an exchange rate or trade balance or deficit/surplus variable without having to define it in model definition)
I have already provisions ready to push.4.6Marco RattoMarco Rattohttps://git.dynare.org/Dynare/dynare/issues/1016Clean up setting of options in dynare_sensitivity.m2019-11-21T08:36:43ZJohannes Pfeifer Clean up setting of options in dynare_sensitivity.mCurrently, it is very intransparent and prone to bugs.
- `neighborhood_width` forces
```
if options_gsa.neighborhood_width,
options_gsa.pprior=0;
options_gsa.ppost=0;
end
```
but the manual says that `neighborhood_width` only works when `pprior=0` and `ppost=0`. This seems like a bug. If we reset options set by the user, we should consistently provide warnings on the screen.
- Even more problematic, without any indication in the manual, using `morris=1` overwrites almost all other user-specified options:
```
if options_gsa.morris==1,
if ~options_gsa.identification,
options_gsa.redform=1;
end
options_gsa.pprior=1;
options_gsa.ppost=0;
%options_gsa.stab=1;
options_gsa.glue=0;
options_gsa.rmse=0;
options_gsa.load_rmse=0;
options_gsa.alpha2_stab=1;
options_gsa.ksstat=1;
options_gsa.pvalue_ks=0;
options_gsa.pvalue_corr=0;
OutputDirectoryName = CheckPath('gsa/screen',M_.dname);
else
OutputDirectoryName = CheckPath('gsa',M_.dname);
end
```
In particular, that results in none of the user-requested output being displayed. See http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=7115. @rattoma Is there a particular reason for this? I could not find any apparent incompatibility of `morris=1` with e.g. posterior sampling.
Currently, it is very intransparent and prone to bugs.
- `neighborhood_width` forces
```
if options_gsa.neighborhood_width,
options_gsa.pprior=0;
options_gsa.ppost=0;
end
```
but the manual says that `neighborhood_width` only works when `pprior=0` and `ppost=0`. This seems like a bug. If we reset options set by the user, we should consistently provide warnings on the screen.
- Even more problematic, without any indication in the manual, using `morris=1` overwrites almost all other user-specified options:
```
if options_gsa.morris==1,
if ~options_gsa.identification,
options_gsa.redform=1;
end
options_gsa.pprior=1;
options_gsa.ppost=0;
%options_gsa.stab=1;
options_gsa.glue=0;
options_gsa.rmse=0;
options_gsa.load_rmse=0;
options_gsa.alpha2_stab=1;
options_gsa.ksstat=1;
options_gsa.pvalue_ks=0;
options_gsa.pvalue_corr=0;
OutputDirectoryName = CheckPath('gsa/screen',M_.dname);
else
OutputDirectoryName = CheckPath('gsa',M_.dname);
end
```
In particular, that results in none of the user-requested output being displayed. See http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=7115. @rattoma Is there a particular reason for this? I could not find any apparent incompatibility of `morris=1` with e.g. posterior sampling.
Marco RattoMarco Rattohttps://git.dynare.org/Dynare/dynare/issues/1651dynare_sensitivity without exogenous variables2019-09-10T09:27:19Zrobvanharreveltdynare_sensitivity without exogenous variablesWhen `dynare_sensitivity` is used for a model without exogenous variables, the following error occurs:
```
Reference to non-existent field 'ghu'.
Error in kalman_transition_matrix (line 42)
B = dr.ghu(iv,:);
```
See the attached file [test1.mod](/uploads/2c7fa958781bb4ea203ecb1d484c9c8d/test1.mod). An easy workaround is to create a dummy exogenous variable (see attached file [test2.mod](/uploads/31ea2681c8f6b2701ed9da63e39c8968/test2.mod)), but it would help if the error message explains that the code does not work for models without exogenous variables.
This issue is similar to issue https://git.dynare.org/Dynare/dynare/issues/1633.When `dynare_sensitivity` is used for a model without exogenous variables, the following error occurs:
```
Reference to non-existent field 'ghu'.
Error in kalman_transition_matrix (line 42)
B = dr.ghu(iv,:);
```
See the attached file [test1.mod](/uploads/2c7fa958781bb4ea203ecb1d484c9c8d/test1.mod). An easy workaround is to create a dummy exogenous variable (see attached file [test2.mod](/uploads/31ea2681c8f6b2701ed9da63e39c8968/test2.mod)), but it would help if the error message explains that the code does not work for models without exogenous variables.
This issue is similar to issue https://git.dynare.org/Dynare/dynare/issues/1633.4.6Marco RattoMarco Rattohttps://git.dynare.org/Dynare/dynare/issues/662Update and fix gsa/set_shocks_param.m2019-06-19T15:38:08ZJohannes Pfeifer Update and fix gsa/set_shocks_param.mApart from an obvious typo (`Sigma_e_` instead `Sigma_e`) it seems as if that file is still missing the update to reflect calibrated covariances (#511).
Apart from an obvious typo (`Sigma_e_` instead `Sigma_e`) it seems as if that file is still missing the update to reflect calibrated covariances (#511).
4.5Marco RattoMarco Rattohttps://git.dynare.org/Dynare/dynare/issues/664Identification and var_exo_det2019-06-19T15:38:08ZJohannes Pfeifer Identification and var_exo_detBoth are not compatible because in calls to the dynamic file the components of `oo_.exo_det_steady_state` neglect x.
Either filter out those cases or make them compatible.
Both are not compatible because in calls to the dynamic file the components of `oo_.exo_det_steady_state` neglect x.
Either filter out those cases or make them compatible.
4.5Marco RattoMarco Rattohttps://git.dynare.org/Dynare/dynare/issues/677Deal with treatment of unit roots in identification2019-06-19T15:38:08ZJohannes Pfeifer Deal with treatment of unit roots in identification```
var y delta_y x z;
varexo eps_x eps_z;
parameters rho sigma_z sigma_x;
// set parameter values
sigma_z=0.001;
sigma_x=0.01;
rho=0.9;
model;
z=rho*z(-1)+sigma_z*eps_z;
x=x(-1)+sigma_x*eps_x;
y=x+z;
delta_y=y-y(-1);
end;
steady_state_model;
x=0;
z=0;
y=0;
delta_y=0;
end;
//set shock variances
shocks;
var eps_z=1;
var eps_x=1;
end;
steady;
check;
varobs y delta_y;
stoch_simul(order=1,irf=0);
estimated_params;
rho, 0.9;
sigma_z, 0.01;
sigma_x, 0.01;
end;
options_.diffuse_filter=1;
identification(lik_init=3,advanced=1);
```
The treatment of unit roots seems unsatisfactory.
First, one needs to specify
`options_.diffuse_filter=1;`
because `options_` used in `dynare_estimation_init` does not inherit the `lik_init` from the `identification` command (used only in `options_ident`) and also does not accept `diffuse_filter`.
Second, some graphs are empty. My guess is because some unconditional moments are infinite.
```
var y delta_y x z;
varexo eps_x eps_z;
parameters rho sigma_z sigma_x;
// set parameter values
sigma_z=0.001;
sigma_x=0.01;
rho=0.9;
model;
z=rho*z(-1)+sigma_z*eps_z;
x=x(-1)+sigma_x*eps_x;
y=x+z;
delta_y=y-y(-1);
end;
steady_state_model;
x=0;
z=0;
y=0;
delta_y=0;
end;
//set shock variances
shocks;
var eps_z=1;
var eps_x=1;
end;
steady;
check;
varobs y delta_y;
stoch_simul(order=1,irf=0);
estimated_params;
rho, 0.9;
sigma_z, 0.01;
sigma_x, 0.01;
end;
options_.diffuse_filter=1;
identification(lik_init=3,advanced=1);
```
The treatment of unit roots seems unsatisfactory.
First, one needs to specify
`options_.diffuse_filter=1;`
because `options_` used in `dynare_estimation_init` does not inherit the `lik_init` from the `identification` command (used only in `options_ident`) and also does not accept `diffuse_filter`.
Second, some graphs are empty. My guess is because some unconditional moments are infinite.
4.5Marco RattoMarco Rattohttps://git.dynare.org/Dynare/dynare/issues/676Fix compatibility of sensitivity and ML estimation2019-06-19T15:38:08ZJohannes Pfeifer Fix compatibility of sensitivity and ML estimationSee http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=5681
Email to Marco:
```
There is an obvious bug in set_shocks_param.m. Sigma_e_ should be just Sigma_e. But there seems to be more. In stab_map_.m in
if pprior,
for j=1:nshock,
if opt_gsa.morris~=1,
lpmat0(:,j) = randperm(Nsam)'./(Nsam+1); %latin hypercube
end
if opt_gsa.prior_range
lpmat0(:,j)=lpmat0(:,j).*(bayestopt_.ub(j)-bayestopt_.lb(j))+bayestopt_.lb(j);
end
end
bayestopt_.ub and lb are accessed and they are Inf. lpmat0 then has a bunch of NaNs that should not be there. This seems to be due to ML estimation and should probably be filtered out.
```
See http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=5681
Email to Marco:
```
There is an obvious bug in set_shocks_param.m. Sigma_e_ should be just Sigma_e. But there seems to be more. In stab_map_.m in
if pprior,
for j=1:nshock,
if opt_gsa.morris~=1,
lpmat0(:,j) = randperm(Nsam)'./(Nsam+1); %latin hypercube
end
if opt_gsa.prior_range
lpmat0(:,j)=lpmat0(:,j).*(bayestopt_.ub(j)-bayestopt_.lb(j))+bayestopt_.lb(j);
end
end
bayestopt_.ub and lb are accessed and they are Inf. lpmat0 then has a bunch of NaNs that should not be there. This seems to be due to ML estimation and should probably be filtered out.
```
4.5Marco RattoMarco Rattohttps://git.dynare.org/Dynare/dynare/issues/764Fix initialization of variables in dynare_sensitivity routine2019-06-19T15:38:04ZJohannes Pfeifer Fix initialization of variables in dynare_sensitivity routineSome of the variables are not properly initialized, grow within loops, and/or are not set in all cases. The `ls2003a.mod` from the tests-folder crashes with `prior_range=1` for example crashes because of this when no standard deviations are estimated, i.e. when using
```
estimated_params;
psi1 , gamma_pdf,1.5,0.5;
psi2 , gamma_pdf,0.25,0.125;
psi3 , gamma_pdf,0.25,0.125;
rho_R ,beta_pdf,0.5,0.2;
alpha ,beta_pdf,0.3,0.1;
rr ,gamma_pdf,2.5,1;
k , gamma_pdf,0.5,0.25;
tau ,gamma_pdf,0.5,0.2;
rho_q ,beta_pdf,0.4,0.2;
rho_A ,beta_pdf,0.5,0.2;
rho_ys ,beta_pdf,0.8,0.1;
rho_pies,beta_pdf,0.7,0.15;
// stderr e_R,inv_gamma_pdf,1.2533,0.6551;
// stderr e_q,inv_gamma_pdf,2.5066,1.3103;
// stderr e_A,inv_gamma_pdf,1.2533,0.6551;
// stderr e_ys,inv_gamma_pdf,1.2533,0.6551;
// stderr e_pies,inv_gamma_pdf,1.88,0.9827;
end;
```
With `prior_range=0` the respective field associated with estimated shocks is correctly set to an empty array and everything works.
Some of the variables are not properly initialized, grow within loops, and/or are not set in all cases. The `ls2003a.mod` from the tests-folder crashes with `prior_range=1` for example crashes because of this when no standard deviations are estimated, i.e. when using
```
estimated_params;
psi1 , gamma_pdf,1.5,0.5;
psi2 , gamma_pdf,0.25,0.125;
psi3 , gamma_pdf,0.25,0.125;
rho_R ,beta_pdf,0.5,0.2;
alpha ,beta_pdf,0.3,0.1;
rr ,gamma_pdf,2.5,1;
k , gamma_pdf,0.5,0.25;
tau ,gamma_pdf,0.5,0.2;
rho_q ,beta_pdf,0.4,0.2;
rho_A ,beta_pdf,0.5,0.2;
rho_ys ,beta_pdf,0.8,0.1;
rho_pies,beta_pdf,0.7,0.15;
// stderr e_R,inv_gamma_pdf,1.2533,0.6551;
// stderr e_q,inv_gamma_pdf,2.5066,1.3103;
// stderr e_A,inv_gamma_pdf,1.2533,0.6551;
// stderr e_ys,inv_gamma_pdf,1.2533,0.6551;
// stderr e_pies,inv_gamma_pdf,1.88,0.9827;
end;
```
With `prior_range=0` the respective field associated with estimated shocks is correctly set to an empty array and everything works.
4.5Marco RattoMarco Rattohttps://git.dynare.org/Dynare/dynare/issues/766Deal with correlations in identification2019-06-19T15:38:04ZJohannes Pfeifer Deal with correlations in identificationCurrently, `identification` does not support specified correlations and simply crashes. We should either support this or block it. See http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=6156
Currently, `identification` does not support specified correlations and simply crashes. We should either support this or block it. See http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=6156
4.5Marco RattoMarco Rattohttps://git.dynare.org/Dynare/dynare/issues/781deal with dseries in dynare_identification.m2019-06-19T15:38:04ZHoutan Bastanideal with dseries in dynare_identification.mThe following test files break under Octave:
- `identification/kim/kim2.mod`
- `identification/as2007/as2007.mod`
The problem is at line 134 in dynare_identification.m as `info` is not a method in the `dseries` called `dataset_`. Fix probably consists of replacing `dataset_.info` with `dataset_info`, but @rattoma should verify this change.....
The following test files break under Octave:
- `identification/kim/kim2.mod`
- `identification/as2007/as2007.mod`
The problem is at line 134 in dynare_identification.m as `info` is not a method in the `dseries` called `dataset_`. Fix probably consists of replacing `dataset_.info` with `dataset_info`, but @rattoma should verify this change.....
4.5Marco RattoMarco Rattohttps://git.dynare.org/Dynare/dynare/issues/789update default values for sensitivity options in doc2019-06-19T15:38:04ZHoutan Bastaniupdate default values for sensitivity options in docIt seems as though some default values in the documentation do not accord with the default values in `dynare_sensitivity.m`. e.g. `alpha_rmse`, `ksstat_redform`. Please review the defaults and update the manual.
It seems as though some default values in the documentation do not accord with the default values in `dynare_sensitivity.m`. e.g. `alpha_rmse`, `ksstat_redform`. Please review the defaults and update the manual.
Marco RattoJohannes Pfeifer Marco Rattohttps://git.dynare.org/Dynare/dynare/issues/796corrcoef in octave2019-06-19T15:38:03ZMarco Rattocorrcoef in octaveAfter my latest commit, gsa crashes with octave. It turns out that the `corrcoef` function in octave is different from natlab, in that no second output argument is given (the pvalue of the corr-coef).
Now, there is a forge package for octave
http://octave.sourceforge.net/nan/function/corrcoef.html
that contains such an extended corrcoef for octave. Could we include that function is we are using octave?
After my latest commit, gsa crashes with octave. It turns out that the `corrcoef` function in octave is different from natlab, in that no second output argument is given (the pvalue of the corr-coef).
Now, there is a forge package for octave
http://octave.sourceforge.net/nan/function/corrcoef.html
that contains such an extended corrcoef for octave. Could we include that function is we are using octave?
4.5Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/issues/945Fix bug in identification when estimating only standard deviations2019-06-19T15:37:58ZJohannes Pfeifer Fix bug in identification when estimating only standard deviationsSee email from 05/23/15.
See email from 05/23/15.
4.5https://git.dynare.org/Dynare/dynare/issues/1105Fix several identification issues2019-06-19T15:37:52ZJohannes Pfeifer Fix several identification issuesConsider the following mod-file
```
var C Y T Dd;
varexo eps_1 eps_2 eps_3;
parameters root1 root2;
//rho1=1.5;
//rho2=-0.6;
root1=0.95; //root1=1.5/2+sqrt((1.5/2)^2+(-0.6))
root2=0.55; //root1=1.5/2-sqrt((1.5/2)^2+(-0.6))
model;
// parameter conversion
# rho1= (root1+root2);
# rho2= - root1*root2;
// model equation
Y = T + C;
C = rho1*C(-1)+rho2*C(-2)+ eps_1;
(T-T(-1))-(T(-1)-T(-2))= Dd(-1) + eps_2-eps_2(-1);
Dd = eps_3;
end;
// 2. Steady-state
steady_state_model;
T = 1;
Y = 1;
Dd=0;
C = 0;
end;
shocks;
var eps_1; stderr 0.1;
var eps_2; stderr 0.1;
var eps_3; stderr 0.1;
end;
stoch_simul(periods=2501, order=1);
save d_obs Y;
//3.2 ML Estimation
estimated_params;
stderr eps_1, 0.01, 0, 1;
stderr eps_2, 0.01, 0, 1;
stderr eps_3, 0.01, 0, 1;
root1, 0.95, -0.9999, 0.9999;
root2, 0.55, -0.9999, 0.9999;
end;
varobs Y;
identification(diffuse_filter);
estimation(datafile=d_obs, presample=4, first_obs=1, mode_compute=4, mode_check, diffuse_filter); // simulated data (MLE)
```
1. The problem is that after `identification_analysis` resets the number of autocorrelations, we have the line
`evalin('caller',['options_ident.ar=',int2str(nlags),';']);`
that is, only in the original caller, which is `dynare_identification.m`, is it reset. When the mod-file now reaches `simulated_moment_uncertainty.m` the variable accessed is `options` and not `options_ident` where `ar` is still at the old value.
I am not sure what is the best design choice to solve this issue. That is why I would leave it to you.
2. Now use
```
estimated_params;
//stderr eps_1, 0.01, 0, 1;
stderr eps_2, 0.01, 0, 1;
//stderr eps_3, 0.01, 0, 1;
root1, 0.95, -0.9999, 0.9999;
// root2, 0.55, -0.9999, 0.9999;
end;
```
instead and there will be a different crash due to nonconformable dimensions in `S=[S;zeros(size(JJ,2)-length(indJJ),1)];` in `identification_analysis`
1. I wonder why the standard deviation of eps_2 is not identifiable in the original mod-file, but the likelihood function shows curvature, although ML is used.
Consider the following mod-file
```
var C Y T Dd;
varexo eps_1 eps_2 eps_3;
parameters root1 root2;
//rho1=1.5;
//rho2=-0.6;
root1=0.95; //root1=1.5/2+sqrt((1.5/2)^2+(-0.6))
root2=0.55; //root1=1.5/2-sqrt((1.5/2)^2+(-0.6))
model;
// parameter conversion
# rho1= (root1+root2);
# rho2= - root1*root2;
// model equation
Y = T + C;
C = rho1*C(-1)+rho2*C(-2)+ eps_1;
(T-T(-1))-(T(-1)-T(-2))= Dd(-1) + eps_2-eps_2(-1);
Dd = eps_3;
end;
// 2. Steady-state
steady_state_model;
T = 1;
Y = 1;
Dd=0;
C = 0;
end;
shocks;
var eps_1; stderr 0.1;
var eps_2; stderr 0.1;
var eps_3; stderr 0.1;
end;
stoch_simul(periods=2501, order=1);
save d_obs Y;
//3.2 ML Estimation
estimated_params;
stderr eps_1, 0.01, 0, 1;
stderr eps_2, 0.01, 0, 1;
stderr eps_3, 0.01, 0, 1;
root1, 0.95, -0.9999, 0.9999;
root2, 0.55, -0.9999, 0.9999;
end;
varobs Y;
identification(diffuse_filter);
estimation(datafile=d_obs, presample=4, first_obs=1, mode_compute=4, mode_check, diffuse_filter); // simulated data (MLE)
```
1. The problem is that after `identification_analysis` resets the number of autocorrelations, we have the line
`evalin('caller',['options_ident.ar=',int2str(nlags),';']);`
that is, only in the original caller, which is `dynare_identification.m`, is it reset. When the mod-file now reaches `simulated_moment_uncertainty.m` the variable accessed is `options` and not `options_ident` where `ar` is still at the old value.
I am not sure what is the best design choice to solve this issue. That is why I would leave it to you.
2. Now use
```
estimated_params;
//stderr eps_1, 0.01, 0, 1;
stderr eps_2, 0.01, 0, 1;
//stderr eps_3, 0.01, 0, 1;
root1, 0.95, -0.9999, 0.9999;
// root2, 0.55, -0.9999, 0.9999;
end;
```
instead and there will be a different crash due to nonconformable dimensions in `S=[S;zeros(size(JJ,2)-length(indJJ),1)];` in `identification_analysis`
1. I wonder why the standard deviation of eps_2 is not identifiable in the original mod-file, but the likelihood function shows curvature, although ML is used.
https://git.dynare.org/Dynare/dynare/issues/1147Do remaining tasks for trends and prefiltering changes2019-06-19T15:37:52ZJohannes Pfeifer Do remaining tasks for trends and prefiltering changesLeft after #1145:
- Check treatment of various options and trends in smoother used in `imcforecast.m`
- Check treatment of these issues in `identification`
- Adjust `convert_dyn_45_to_44` to reflect these changes
- Add trend estimate to output from `prior_posterior_statistics_core`
Left after #1145:
- Check treatment of various options and trends in smoother used in `imcforecast.m`
- Check treatment of these issues in `identification`
- Adjust `convert_dyn_45_to_44` to reflect these changes
- Add trend estimate to output from `prior_posterior_statistics_core`
4.5Johannes Pfeifer Johannes Pfeifer https://git.dynare.org/Dynare/dynare/issues/1237Investigate identification problem2019-06-19T15:37:49ZJohannes Pfeifer Investigate identification problemhttp://www.dynare.org/phpBB3/viewtopic.php?f=1&t=8234
Sent email with mod-file to @rattoma on June 1, 2016
http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=8234
Sent email with mod-file to @rattoma on June 1, 2016
4.5Marco RattoMarco Rattohttps://git.dynare.org/Dynare/dynare/issues/1266bug with eig in Matlab R2012a2019-06-19T15:37:49ZHoutan Bastanibug with eig in Matlab R2012aOn line 197 of `matlab/identification_analysis.m`, we have `[V,D,W]=eig(cc);`. In older versions of Matlab, eig only has two output arguments and hence this causes an error. To calculate `W`, the left eigenvectors of cc, the documentation recommends `[W,junk] = eig(cc.'); W = conj(W)` separately.
On line 197 of `matlab/identification_analysis.m`, we have `[V,D,W]=eig(cc);`. In older versions of Matlab, eig only has two output arguments and hence this causes an error. To calculate `W`, the left eigenvectors of cc, the documentation recommends `[W,junk] = eig(cc.'); W = conj(W)` separately.
4.5Marco RattoMarco Rattohttps://git.dynare.org/Dynare/dynare/issues/1642Bug in analytical computations of second-order params derivs (d2A and d2Om)2019-03-27T11:52:59ZWilli Mutschlerwilli@mutschler.euBug in analytical computations of second-order params derivs (d2A and d2Om)The function `get_first_order_solution_params_deriv.m` (previously `getH.m`) does not compute the second-order derivatives `d2A` and `d2Om` correctly when using analytical derivatives (kronflag=0|1). If we use numerical derivatives (kronflag=-1|-2) the computations are correct.
To replicate the bug, I looked at the Brock and Mirman model (i.e. RBC model with log utility and full depreciation), where we know analytically the policy functions, i.e. also the Kalman transition matrices of a first-order approximation (A, B and Om) analytically. Hence, using symbolic computations it is possible to compute the true `d2A` and `d2Om` and compare the values to dynare.
Here is a mod file to replicate the bug:
[BrockMirmanBug.mod](/uploads/006601083ca694efc36c5b9b396c3aa9/BrockMirmanBug.mod)
and the corresponding matlab file that computes the true objects of the Brock Mirman Model analytically using Matlab's symbolic toolbox:
[BrockMirmanTruePolicyAndDerivatives.m](/uploads/f1cf3e22d26d7e904b6e49764520ee5e/BrockMirmanTruePolicyAndDerivatives.m)
@rattoma is already aware of this bug.The function `get_first_order_solution_params_deriv.m` (previously `getH.m`) does not compute the second-order derivatives `d2A` and `d2Om` correctly when using analytical derivatives (kronflag=0|1). If we use numerical derivatives (kronflag=-1|-2) the computations are correct.
To replicate the bug, I looked at the Brock and Mirman model (i.e. RBC model with log utility and full depreciation), where we know analytically the policy functions, i.e. also the Kalman transition matrices of a first-order approximation (A, B and Om) analytically. Hence, using symbolic computations it is possible to compute the true `d2A` and `d2Om` and compare the values to dynare.
Here is a mod file to replicate the bug:
[BrockMirmanBug.mod](/uploads/006601083ca694efc36c5b9b396c3aa9/BrockMirmanBug.mod)
and the corresponding matlab file that computes the true objects of the Brock Mirman Model analytically using Matlab's symbolic toolbox:
[BrockMirmanTruePolicyAndDerivatives.m](/uploads/f1cf3e22d26d7e904b6e49764520ee5e/BrockMirmanTruePolicyAndDerivatives.m)
@rattoma is already aware of this bug.Marco RattoMarco Ratto