dynare issueshttps://git.dynare.org/Dynare/dynare/issues2019-06-19T15:37:49Zhttps://git.dynare.org/Dynare/dynare/issues/1240user_has_matlab_license2019-06-19T15:37:49ZMarco Rattouser_has_matlab_licenseDynare checks license but for onsite licenses, toolboxes could be licensed but not installed on the current machine. This would be visible with `ver`, even if I am not sure of the overall behavior of ver ...
Dynare checks license but for onsite licenses, toolboxes could be licensed but not installed on the current machine. This would be visible with `ver`, even if I am not sure of the overall behavior of ver ...
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/1234Check whether fast_kalman_filter is compatible with non-stationary states2019-06-19T15:37:49ZJohannes Pfeifer Check whether fast_kalman_filter is compatible with non-stationary statesFrom the Herbst (2015)-paper:
`This seems like a difficult problem, because the factorization is not obvious, and, in our
experience, even finding α consistently can be hard. Fortunately, the problem becomes
much easier once it is known that the states are stationary.`
In a nonstationary model I get a complex likelihood.
From the Herbst (2015)-paper:
`This seems like a difficult problem, because the factorization is not obvious, and, in our
experience, even finding α consistently can be hard. Fortunately, the problem becomes
much easier once it is known that the states are stationary.`
In a nonstationary model I get a complex likelihood.
https://git.dynare.org/Dynare/dynare/issues/1232Remove onlyclearglobals option2019-06-19T15:37:49ZJohannes Pfeifer Remove onlyclearglobals optionIt was introduced in master, but is now redundant with the `clear all` command being removed due to Matlab's JIT
It was introduced in master, but is now redundant with the `clear all` command being removed due to Matlab's JIT
4.5Johannes Pfeifer Johannes Pfeifer https://git.dynare.org/Dynare/dynare/issues/1231Fix remaining Kalman-filter problems after #7382019-06-19T15:37:49ZJohannes Pfeifer Fix remaining Kalman-filter problems after #738In particular, the univariate filter may return wrong results with measurement error
TBD from #738
- Fix all bugs that result in unit tests crashing
- Improve unit tests to compare likelihood results for consistency
- Update and enable other unit tests for Kalman filter in kalman/likelihood directory
Please assign the ticket to me. Milestone should be 4.5
In particular, the univariate filter may return wrong results with measurement error
TBD from #738
- Fix all bugs that result in unit tests crashing
- Improve unit tests to compare likelihood results for consistency
- Update and enable other unit tests for Kalman filter in kalman/likelihood directory
Please assign the ticket to me. Milestone should be 4.5
https://git.dynare.org/Dynare/dynare/issues/1229external functions and third order perturbation2019-06-19T15:37:49ZStéphane Adjemianstepan@dynare.orgexternal functions and third order perturbationIt appears that we did not implement the possibility to use external functions when solving DSGE models at third order. I thought that when the derivates are not provided by the user, Dynare computed the derivates numerically. It seems that this mechanism is not triggered at third order. Is this intentional?
It appears that we did not implement the possibility to use external functions when solving DSGE models at third order. I thought that when the derivates are not provided by the user, Dynare computed the derivates numerically. It seems that this mechanism is not triggered at third order. Is this intentional?
https://git.dynare.org/Dynare/dynare/issues/1227Solve use_dll-incompatibility problem on Windows in master2019-06-19T15:37:49ZJohannes Pfeifer Solve use_dll-incompatibility problem on Windows in masterAfter merging the `temporary_terms`-branch (https://github.com/DynareTeam/dynare/commit/127637ffd672fdd8143ee13f2a38234e597d94d3) the `c`-files created are not `C89`-compatible, but require `C99`. This is a problem for Windows machines as Visual Studio before version 2015 only supported `C89`, resulting in errors of the form
`error C2143: syntax error : missing ';' before 'type'`
Before Matlab version `R2014b` users could use the `cygwin`-option by using the provided `mexopts-win64.bat` from http://www.dynare.org/DynareWiki/ConfigureMatlabWindowsForMexCompilation, which should not have this restriction. Since `R2015b`, `mingw` is available, which also supports `C99` (#1226). Moreover, Visual Studio 2015 finally supports `C99` and has a free available version that is supported since `R2015b`. That leaves 64bit Matlab-versions between `R2014a` and `R2015a` unable to deal with the problem unless someone figures out how to solve #641 for `cygwin` (potentially following the advice on how to set up the `xml`-file at http://stackoverflow.com/questions/8552580/using-gcc-mingw-as-matlabs-mex-compiler). Given that there seems to be not that much demand for `use_dll` on Windows, I would propose for 4.5 to focus on the `mingw`-support and state the above restrictions clearly in the release notes and the manual
After merging the `temporary_terms`-branch (https://github.com/DynareTeam/dynare/commit/127637ffd672fdd8143ee13f2a38234e597d94d3) the `c`-files created are not `C89`-compatible, but require `C99`. This is a problem for Windows machines as Visual Studio before version 2015 only supported `C89`, resulting in errors of the form
`error C2143: syntax error : missing ';' before 'type'`
Before Matlab version `R2014b` users could use the `cygwin`-option by using the provided `mexopts-win64.bat` from http://www.dynare.org/DynareWiki/ConfigureMatlabWindowsForMexCompilation, which should not have this restriction. Since `R2015b`, `mingw` is available, which also supports `C99` (#1226). Moreover, Visual Studio 2015 finally supports `C99` and has a free available version that is supported since `R2015b`. That leaves 64bit Matlab-versions between `R2014a` and `R2015a` unable to deal with the problem unless someone figures out how to solve #641 for `cygwin` (potentially following the advice on how to set up the `xml`-file at http://stackoverflow.com/questions/8552580/using-gcc-mingw-as-matlabs-mex-compiler). Given that there seems to be not that much demand for `use_dll` on Windows, I would propose for 4.5 to focus on the `mingw`-support and state the above restrictions clearly in the release notes and the manual
4.5https://git.dynare.org/Dynare/dynare/issues/1226Support mingw-compiler on Windows2019-06-19T15:37:49ZJohannes Pfeifer Support mingw-compiler on WindowsSince Matlab2014a, the `mexopts.bat` cannot be used anymore to set the mex-compiler to `cygwin`, rendering it pretty much useless for most recent versions. However, Mathworks now has a MinGW-addon (http://de.mathworks.com/help/matlab/matlab_external/install-mingw-support-package.html) that we should support.
For this, we need to
1. Allow for a `mingw` command line flag
2. Adjust `dyn_mex` with the respective case distinction and necessary flags
3. Update http://www.dynare.org/DynareWiki/ConfigureMatlabWindowsForMexCompilation
Since Matlab2014a, the `mexopts.bat` cannot be used anymore to set the mex-compiler to `cygwin`, rendering it pretty much useless for most recent versions. However, Mathworks now has a MinGW-addon (http://de.mathworks.com/help/matlab/matlab_external/install-mingw-support-package.html) that we should support.
For this, we need to
1. Allow for a `mingw` command line flag
2. Adjust `dyn_mex` with the respective case distinction and necessary flags
3. Update http://www.dynare.org/DynareWiki/ConfigureMatlabWindowsForMexCompilation
4.5Johannes Pfeifer Houtan BastaniJohannes Pfeifer https://git.dynare.org/Dynare/dynare/issues/1215qz_criterium in estimation2019-06-19T15:37:49ZMarco Rattoqz_criterium in estimationI think it would be useful to allow option `qz_criterium` also in estimation, similarly to simulation. Would it be possible? Is there any strong reason for not allowing this?
I think it would be useful to allow option `qz_criterium` also in estimation, similarly to simulation. Would it be possible? Is there any strong reason for not allowing this?
4.5https://git.dynare.org/Dynare/dynare/issues/1209rework recent static model preprocessor changes2019-06-19T15:37:49ZHoutan Bastanirework recent static model preprocessor changesThe changes to the preprocessor made in 6e514b7d1bfc4b76fbc483da1da0ae7416de7cda have been made in the `computingPass` when they should have been made in the `transformPass`. Move these changes from `StaticModel::computingPass` to `DynamicModel::toStatic`
The changes to the preprocessor made in 6e514b7d1bfc4b76fbc483da1da0ae7416de7cda have been made in the `computingPass` when they should have been made in the `transformPass`. Move these changes from `StaticModel::computingPass` to `DynamicModel::toStatic`
4.5Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/issues/1211Check newrat-implementation and potentially port Michel's changes2019-06-19T15:37:49ZJohannes Pfeifer Check newrat-implementation and potentially port Michel's changesDuring his first try of removing `objective_function_penalty_base` @MichelJuillard made various changes to `newrat` that were reverted, but potentially still need to be ported to `master`. But I am not entirely sure what these commits do. @rattoma Could you maybe have a look.
1. In the reverted commits https://github.com/DynareTeam/dynare/commit/fe077fc7103658aab7becba95167aa9d240b07f1 and https://github.com/DynareTeam/dynare/commit/f48a026d89828e9e322333263f56b733a719eb34 the initialization of `mr_hessian` was removed.
2. In https://github.com/DynareTeam/dynare/commit/5ade8d7c6fc71cc4ee4ffbb27dad2ed6b4cf8ccd the `newratflag`was passed to the optimizer, but this was reverted in https://github.com/DynareTeam/dynare/commit/d4cf3576e468202df9d1582a045dfcfd74e2e7db . What is the correct setting here?
3. In https://github.com/DynareTeam/dynare/commit/5ade8d7c6fc71cc4ee4ffbb27dad2ed6b4cf8ccd the part
```
if analytic_derivation,
hhx=hh;
else
hhx = reshape(dum,nx,nx);
end
```
was replaced by
`hhx=hh;`
But when I tried this, the program crashed in tests.
During his first try of removing `objective_function_penalty_base` @MichelJuillard made various changes to `newrat` that were reverted, but potentially still need to be ported to `master`. But I am not entirely sure what these commits do. @rattoma Could you maybe have a look.
1. In the reverted commits https://github.com/DynareTeam/dynare/commit/fe077fc7103658aab7becba95167aa9d240b07f1 and https://github.com/DynareTeam/dynare/commit/f48a026d89828e9e322333263f56b733a719eb34 the initialization of `mr_hessian` was removed.
2. In https://github.com/DynareTeam/dynare/commit/5ade8d7c6fc71cc4ee4ffbb27dad2ed6b4cf8ccd the `newratflag`was passed to the optimizer, but this was reverted in https://github.com/DynareTeam/dynare/commit/d4cf3576e468202df9d1582a045dfcfd74e2e7db . What is the correct setting here?
3. In https://github.com/DynareTeam/dynare/commit/5ade8d7c6fc71cc4ee4ffbb27dad2ed6b4cf8ccd the part
```
if analytic_derivation,
hhx=hh;
else
hhx = reshape(dum,nx,nx);
end
```
was replaced by
`hhx=hh;`
But when I tried this, the program crashed in tests.
4.5https://git.dynare.org/Dynare/dynare/issues/1203In the latest unstable, sparse_hessian_times_B_kronecker_C.mexw64 has a depen...2019-06-19T15:37:50ZTom HoldenIn the latest unstable, sparse_hessian_times_B_kronecker_C.mexw64 has a dependency on libgomp-1.dllI was getting errors about missing dependencies. Running Dependency Walker on it revealed libgomp-1.dll as the problem. Copying this across from MinGW fixed the issue.
I was getting errors about missing dependencies. Running Dependency Walker on it revealed libgomp-1.dll as the problem. Copying this across from MinGW fixed the issue.
4.5https://git.dynare.org/Dynare/dynare/issues/1201Depth issue2019-06-19T15:37:50ZStéphane Adjemianstepan@dynare.orgDepth issueLooking into #1175 , by reverting commit 3c7e60b744567f6f39a9c611bce6dcaadcd52bc6, I obtained the following error from matlab when trying to run Christiano-Motto-Rostagno model (the one in subfolder `figure4` of the archive available [here](http://faculty.wcas.northwestern.edu/~lchrist/research/ECB/risk_shocks/20100922_data.zip)
```
Error: File: cmr_static.m Line: 1292 Column: 16331
Nesting of {, [, and ( cannot exceed a depth of 32.
```
@MichelJuillard May this be a consequence of your patch about on auxiliary variables in steady state and static files (see #1133)?
Looking into #1175 , by reverting commit 3c7e60b744567f6f39a9c611bce6dcaadcd52bc6, I obtained the following error from matlab when trying to run Christiano-Motto-Rostagno model (the one in subfolder `figure4` of the archive available [here](http://faculty.wcas.northwestern.edu/~lchrist/research/ECB/risk_shocks/20100922_data.zip)
```
Error: File: cmr_static.m Line: 1292 Column: 16331
Nesting of {, [, and ( cannot exceed a depth of 32.
```
@MichelJuillard May this be a consequence of your patch about on auxiliary variables in steady state and static files (see #1133)?
4.5Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/issues/1202Provide Windows cross compilation instructions2019-06-19T15:37:50ZTom HoldenProvide Windows cross compilation instructionsI know building on Windows is no-longer supported. Still, building for Windows ought to be supported.
Thus, it would be a great help if there were e.g. a script for cross compiling for Windows from Linux.
The dependencies make this rather painful.
I know building on Windows is no-longer supported. Still, building for Windows ought to be supported.
Thus, it would be a great help if there were e.g. a script for cross compiling for Windows from Linux.
The dependencies make this rather painful.
https://git.dynare.org/Dynare/dynare/issues/1199Check mode-file related options of slice2019-06-19T15:37:50ZJohannes Pfeifer Check mode-file related options of sliceAs discussed with @rattoma it is not clear the preprocessor can handle the necessary inputs which must be a set of vectors or an array of strings. We might need to delete the mode option from the manual and provide an example of the mode_files option
As discussed with @rattoma it is not clear the preprocessor can handle the necessary inputs which must be a set of vectors or an array of strings. We might need to delete the mode option from the manual and provide an example of the mode_files option
Marco RattoMarco Rattohttps://git.dynare.org/Dynare/dynare/issues/1195Fix parallel error/warning on Windows systems2019-06-19T15:37:50ZJohannes Pfeifer Fix parallel error/warning on Windows systems`dynareParallelDelete.m` has in line 51 a delete statment containing a `$` sign, which is not valid Windows code.
`dynareParallelDelete.m` has in line 51 a delete statment containing a `$` sign, which is not valid Windows code.
5.0Marco RattoMarco Rattohttps://git.dynare.org/Dynare/dynare/issues/1194Allow for comments in parallel configuration files2019-06-19T15:37:50ZJohannes Pfeifer Allow for comments in parallel configuration filesWe would need a way to add comments to configuration files. @rattoma were thinking about using the hashtag # for this (unless someone envisions a role for it on Windows/MAC/Unix).
We would need a way to add comments to configuration files. @rattoma were thinking about using the hashtag # for this (unless someone envisions a role for it on Windows/MAC/Unix).
4.5Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/issues/1193Make preprocessor recognize state variables introduced by optimal policy2019-06-19T15:37:50ZJohannes Pfeifer Make preprocessor recognize state variables introduced by optimal policyIn the mod-file
```
var pai, c, n, r, a;
varexo u;
parameters beta, rho, epsilon, omega, phi, gamma;
beta=0.99;
gamma=3;
omega=17;
epsilon=8;
phi=1;
rho=0.95;
model;
a = rho*a(-1)+u;
1/c = beta*r/(c(+1)*pai(+1));
pai*(pai-1)/c = beta*pai(+1)*(pai(+1)-1)/c(+1)+epsilon*phi*n^(gamma+1)/omega -exp(a)*n*(epsilon-1)/(omega*c);
exp(a)*n = c+(omega/2)*(pai-1)^2;
end;
initval;
r=1;
end;
histval;
a(0)=1;
r(0)=1;
end;
steady_state_model;
a = 0;
pai = beta*r;
c = find_c(0.96,pai,beta,epsilon,phi,gamma,omega);
n = c+(omega/2)*(pai-1)^2;
end;
shocks;
var u; stderr 0.008;
var u;
periods 1;
values 1;
end;
options_.dr_display_tol=0;
planner_objective(ln(c)-phi*((n^(1+gamma))/(1+gamma)));
ramsey_policy(planner_discount=0.99,order=1,instruments=(r));
```
`r` becomes a state variable during Ramsey computations (albeit with 0 coefficients). As a state, one should be able to set its lagged value using `histval`. But this is not possible, as the preprocessor does not recognize `r` as a state.
In the mod-file
```
var pai, c, n, r, a;
varexo u;
parameters beta, rho, epsilon, omega, phi, gamma;
beta=0.99;
gamma=3;
omega=17;
epsilon=8;
phi=1;
rho=0.95;
model;
a = rho*a(-1)+u;
1/c = beta*r/(c(+1)*pai(+1));
pai*(pai-1)/c = beta*pai(+1)*(pai(+1)-1)/c(+1)+epsilon*phi*n^(gamma+1)/omega -exp(a)*n*(epsilon-1)/(omega*c);
exp(a)*n = c+(omega/2)*(pai-1)^2;
end;
initval;
r=1;
end;
histval;
a(0)=1;
r(0)=1;
end;
steady_state_model;
a = 0;
pai = beta*r;
c = find_c(0.96,pai,beta,epsilon,phi,gamma,omega);
n = c+(omega/2)*(pai-1)^2;
end;
shocks;
var u; stderr 0.008;
var u;
periods 1;
values 1;
end;
options_.dr_display_tol=0;
planner_objective(ln(c)-phi*((n^(1+gamma))/(1+gamma)));
ramsey_policy(planner_discount=0.99,order=1,instruments=(r));
```
`r` becomes a state variable during Ramsey computations (albeit with 0 coefficients). As a state, one should be able to set its lagged value using `histval`. But this is not possible, as the preprocessor does not recognize `r` as a state.
4.5.2Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/issues/1187allow to skip 2nd order param derivs2019-06-19T15:37:50ZMarco Rattoallow to skip 2nd order param derivsFor large models, computing the analytic Hessian just produces a too big `_params_derivs.m` file which is untractable.
For running identification or only computing scores, 2nd order derivs would be useless.
@houtanb Would it be possible to tell the pre-processor to only compute 1st order derivatives, i.e. stop writing the `param_derivs` file when it reaches
`if nargout >= 3 ...`
?
2nd order terms could be just defined as empty, and routines (`dsge_likelihood`) possibly asking for 2nd order ones will trap this and just stop.
For large models, computing the analytic Hessian just produces a too big `_params_derivs.m` file which is untractable.
For running identification or only computing scores, 2nd order derivs would be useless.
@houtanb Would it be possible to tell the pre-processor to only compute 1st order derivatives, i.e. stop writing the `param_derivs` file when it reaches
`if nargout >= 3 ...`
?
2nd order terms could be just defined as empty, and routines (`dsge_likelihood`) possibly asking for 2nd order ones will trap this and just stop.
4.5Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/issues/1184Crash in preprocessor in unstable branch2019-06-19T15:37:50ZMarco RattoCrash in preprocessor in unstable branchI get a crash in the preprocessor in the unstable branch, since I rebased my local unstable branch onto the recent commits [pervious preprocessor versions I used date back October 2015 ...] when dealing with our Global Multicountry model.
I get the error both in Windows and MacOS.
In MacOS I get the following message:
`
dynare_m(554,0x7fff7411b300) malloc:
`
`
*** error for object 0x7fda6a60ccd0: pointer being freed was not allocated
`
`
*** set a breakpoint in malloc_error_break to debug
`
apparently what triggers the error is the use of `trend_var` and `deflator` instructions.
When I filter out detrending, pre-processing completes.
I can share a replication package privately.
with older versions of the unstable preprocessor everything went fine.
I get a crash in the preprocessor in the unstable branch, since I rebased my local unstable branch onto the recent commits [pervious preprocessor versions I used date back October 2015 ...] when dealing with our Global Multicountry model.
I get the error both in Windows and MacOS.
In MacOS I get the following message:
`
dynare_m(554,0x7fff7411b300) malloc:
`
`
*** error for object 0x7fda6a60ccd0: pointer being freed was not allocated
`
`
*** set a breakpoint in malloc_error_break to debug
`
apparently what triggers the error is the use of `trend_var` and `deflator` instructions.
When I filter out detrending, pre-processing completes.
I can share a replication package privately.
with older versions of the unstable preprocessor everything went fine.
4.5Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/issues/1183Fix compatibility with matlab 2016a in installer and mex-folder2019-06-19T15:37:51ZStéphane Adjemianstepan@dynare.orgFix compatibility with matlab 2016a in installer and mex-folderI had to revert commit 6072aa0b462484da990ffa00ee39fb141fa9513f (which is PR #1144 by @JohannesPfeifer) because the snapshot build failed this evening. The generated mex files are not saved in the expected directory. They are saved in `mex/matlab/win64-7.8-8.6` instead of `mex/matlab/win64-7.8-9.0`. I did not find where the name of this directory is controlled. @houtanb can you fix this?
I had to revert commit 6072aa0b462484da990ffa00ee39fb141fa9513f (which is PR #1144 by @JohannesPfeifer) because the snapshot build failed this evening. The generated mex files are not saved in the expected directory. They are saved in `mex/matlab/win64-7.8-8.6` instead of `mex/matlab/win64-7.8-9.0`. I did not find where the name of this directory is controlled. @houtanb can you fix this?
4.5Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/issues/1179Fix cross-compilation of Dynare++ for Windows2019-06-19T15:37:51ZJohannes Pfeifer Fix cross-compilation of Dynare++ for WindowsWith the unstable version under Windows 10 I get an error that `libquadmath-0.dll` is missing, while Dynare 4.4.3 still works.
With the unstable version under Windows 10 I get an error that `libquadmath-0.dll` is missing, while Dynare 4.4.3 still works.
4.5Stéphane Adjemianstepan@dynare.orgStéphane Adjemianstepan@dynare.orghttps://git.dynare.org/Dynare/dynare/issues/1178Ship Dynare++ example in Dynare++ folder2019-06-19T15:37:51ZJohannes Pfeifer Ship Dynare++ example in Dynare++ folderI would suggest we provide the example from the documentation, but with a lower order:
```
var Y, C, K, A, H, B;
varexo EPS, NU;
parameters beta, rho, alpha, delta, theta, psi, tau;
alpha = 0.36;
rho = 0.95;
tau = 0.025;
beta = 1/(1.03^0.25);
delta = 0.025;
psi = 0;
theta = 2.95;
model;
C*theta*H^(1+psi) = (1-alpha)*Y;
beta*exp(B)*C/exp(B(1))/C(1)*
(exp(B(1))*alpha*Y(1)/K(1)+1-delta) = 1;
Y = exp(A)*K^alpha*H^(1-alpha);
K = exp(B(-1))*(Y(-1)-C(-1)) + (1-delta)*K(-1);
A = rho*A(-1) + tau*B(-1) + EPS;
B = tau*A(-1) + rho*B(-1) + NU;
end;
initval;
A = 0;
B = 0;
H = ((1-alpha)/(theta*(1-(delta*alpha)
/(1/beta-1+delta))))^(1/(1+psi));
Y = (alpha/(1/beta-1+delta))^(alpha/(1-alpha))*H;
K = alpha/(1/beta-1+delta)*Y;
C = Y - delta*K;
end;
vcov = [0.0002 0.00005;
0.00005 0.0001
];
order = 5;
```
I would suggest we provide the example from the documentation, but with a lower order:
```
var Y, C, K, A, H, B;
varexo EPS, NU;
parameters beta, rho, alpha, delta, theta, psi, tau;
alpha = 0.36;
rho = 0.95;
tau = 0.025;
beta = 1/(1.03^0.25);
delta = 0.025;
psi = 0;
theta = 2.95;
model;
C*theta*H^(1+psi) = (1-alpha)*Y;
beta*exp(B)*C/exp(B(1))/C(1)*
(exp(B(1))*alpha*Y(1)/K(1)+1-delta) = 1;
Y = exp(A)*K^alpha*H^(1-alpha);
K = exp(B(-1))*(Y(-1)-C(-1)) + (1-delta)*K(-1);
A = rho*A(-1) + tau*B(-1) + EPS;
B = tau*A(-1) + rho*B(-1) + NU;
end;
initval;
A = 0;
B = 0;
H = ((1-alpha)/(theta*(1-(delta*alpha)
/(1/beta-1+delta))))^(1/(1+psi));
Y = (alpha/(1/beta-1+delta))^(alpha/(1-alpha))*H;
K = alpha/(1/beta-1+delta)*Y;
C = Y - delta*K;
end;
vcov = [0.0002 0.00005;
0.00005 0.0001
];
order = 5;
```
4.5Stéphane Adjemianstepan@dynare.orgStéphane Adjemianstepan@dynare.orghttps://git.dynare.org/Dynare/dynare/issues/1176Investigate crash in sim1_linear.m2019-06-19T15:37:51ZJohannes Pfeifer Investigate crash in sim1_linear.mThe following mod-file crashes Dynare in master
```
var pi y pi_annual;
varexo x;
parameters kappa beta sigma lambda rho phi_pi phi_y;
kappa=.025;
beta=.995;
sigma=1;
lambda=1;
rho=.8;
phi_pi=1.5;
phi_y=.5;
model(linear);
pi =(kappa/(1+beta*lambda))*(-1/sigma*x+1/kappa*pi(+1)-beta/kappa*pi(+2)+1/sigma*beta*pi(+1))+(beta/(1+beta*lambda))*pi(+1)+(lambda/(1+beta*lambda))*pi(-1);
x=sigma*(y(+1)-y)+pi(+1);
pi_annual=4*pi;
end;
shocks;
var x;
periods 1:1;
values -0.005;
end;
simul(periods=1);
```
Setting periods bigger than 1 solves the issue.
The following mod-file crashes Dynare in master
```
var pi y pi_annual;
varexo x;
parameters kappa beta sigma lambda rho phi_pi phi_y;
kappa=.025;
beta=.995;
sigma=1;
lambda=1;
rho=.8;
phi_pi=1.5;
phi_y=.5;
model(linear);
pi =(kappa/(1+beta*lambda))*(-1/sigma*x+1/kappa*pi(+1)-beta/kappa*pi(+2)+1/sigma*beta*pi(+1))+(beta/(1+beta*lambda))*pi(+1)+(lambda/(1+beta*lambda))*pi(-1);
x=sigma*(y(+1)-y)+pi(+1);
pi_annual=4*pi;
end;
shocks;
var x;
periods 1:1;
values -0.005;
end;
simul(periods=1);
```
Setting periods bigger than 1 solves the issue.
4.5https://git.dynare.org/Dynare/dynare/issues/1177Implement interface for posterior sampling methods2019-06-19T15:37:51ZJohannes Pfeifer Implement interface for posterior sampling methodsRelated to #1174 and #1065
I would propose to use this occasion to further clean up the `options_`-structure and create a field `options_.posterior_sampler_options` that stores as subfields the various options.
The preprocessor should have an option `posterior_sampling_method` that accepts a quoted string that can be `slice`, `random_walk_metropolis_hastings`, `independent_metropolis_hastings` or `tailored_random_block_metropolis_hastings`
It should map into `options_.posterior_sampler_options.posterior_sampling_method` with default
`random_walk_metropolis_hastings`, which replaces the current `options_.posterior_sampling_method`
In addition:
1. We need a subfields `options_.posterior_sampler_options.tarb`, `options_.posterior_sampler_options.rwmh`,`options_.posterior_sampler_options.slice`,
and `options_.posterior_sampler_options.imh` that store the default options for the respective sampler as we already do for different mode_computes.
2. We need the preprocessor to accept name/value pairs like in the already existing `optim`-option in the form of `posterior_sampler_options = (NAME, VALUE,...)`.
It should map into a string `options_.posterior_sampler_options.sampling_opt`, which can then be read out using `read_key_value_string` as we already do in `dynare_minimize_objective`.
3. The already existing but undocumented options `options_.proposal_distribution` and `options_.student_degrees_of_freedom` should now become sampler-specific subfields of the fields introduced in 1.
Related to #1174 and #1065
I would propose to use this occasion to further clean up the `options_`-structure and create a field `options_.posterior_sampler_options` that stores as subfields the various options.
The preprocessor should have an option `posterior_sampling_method` that accepts a quoted string that can be `slice`, `random_walk_metropolis_hastings`, `independent_metropolis_hastings` or `tailored_random_block_metropolis_hastings`
It should map into `options_.posterior_sampler_options.posterior_sampling_method` with default
`random_walk_metropolis_hastings`, which replaces the current `options_.posterior_sampling_method`
In addition:
1. We need a subfields `options_.posterior_sampler_options.tarb`, `options_.posterior_sampler_options.rwmh`,`options_.posterior_sampler_options.slice`,
and `options_.posterior_sampler_options.imh` that store the default options for the respective sampler as we already do for different mode_computes.
2. We need the preprocessor to accept name/value pairs like in the already existing `optim`-option in the form of `posterior_sampler_options = (NAME, VALUE,...)`.
It should map into a string `options_.posterior_sampler_options.sampling_opt`, which can then be read out using `read_key_value_string` as we already do in `dynare_minimize_objective`.
3. The already existing but undocumented options `options_.proposal_distribution` and `options_.student_degrees_of_freedom` should now become sampler-specific subfields of the fields introduced in 1.
4.5https://git.dynare.org/Dynare/dynare/issues/1172Remove or fix dsgevar_posterior_density.m2019-06-19T15:37:51ZJohannes Pfeifer Remove or fix dsgevar_posterior_density.mThe function is nowhere used and is totally buggy as it even does not reflect name changes in the header within the function (e.g. DynareOption instead of options_ )
The function is nowhere used and is totally buggy as it even does not reflect name changes in the header within the function (e.g. DynareOption instead of options_ )
4.5https://git.dynare.org/Dynare/dynare/issues/1165stochastic_solvers calls transition_matrix without passing M_2019-06-19T15:37:51ZTom Holdenstochastic_solvers calls transition_matrix without passing M_transition_matrix optionally takes M_ as an additional argument. If it doesn't get the extra argument, then it uses the global M_.
Given that stochastic_solvers takes M_ as an additional argument, it should also pass this to transition_matrix.
Without this, user code that calls Dynare internals in parallel can be messed up.
transition_matrix optionally takes M_ as an additional argument. If it doesn't get the extra argument, then it uses the global M_.
Given that stochastic_solvers takes M_ as an additional argument, it should also pass this to transition_matrix.
Without this, user code that calls Dynare internals in parallel can be messed up.
https://git.dynare.org/Dynare/dynare/issues/1160Implement filter_covariance option in Bayesian estimation2019-06-19T15:37:51ZJohannes Pfeifer Implement filter_covariance option in Bayesian estimationCurrently only possible in ML and calibrated smoother
Currently only possible in ML and calibrated smoother
5.0https://git.dynare.org/Dynare/dynare/issues/1161Fix selected_variables_only option2019-06-19T15:37:51ZJohannes Pfeifer Fix selected_variables_only optionIn Dynare 4.4.3, we have in `dynare_estimation_1`
```
for i=bayestopt_.smoother_saved_var_list'
i1 = dr.order_var(bayestopt_.smoother_var_list(i));
eval(['oo_.SmoothedVariables.' deblank(M_.endo_names(i1,:)) ' = ' ...
'atT(i,:)'';']);
```
But `bayestopt_.smoother_saved_var_list` only saves the index of the variable in `bayestopt_.smoother_var_list`, not in the decision rules themselves. Therefore, we have to select `atT(bayestopt_.smoother_var_list(i),:)` instead of `atT(i,:)` if `bayestopt_.smoother_var_list` is not equal to `bayestopt_.smoother_saved_var_list`, which happens with `selected_variables_only`
In master the same problem has been ported to `write_smoother_results`
@MichelJuillard @stepan-a Should we try to fix this or should we get rid of the `selected_variables_only` option?
In Dynare 4.4.3, we have in `dynare_estimation_1`
```
for i=bayestopt_.smoother_saved_var_list'
i1 = dr.order_var(bayestopt_.smoother_var_list(i));
eval(['oo_.SmoothedVariables.' deblank(M_.endo_names(i1,:)) ' = ' ...
'atT(i,:)'';']);
```
But `bayestopt_.smoother_saved_var_list` only saves the index of the variable in `bayestopt_.smoother_var_list`, not in the decision rules themselves. Therefore, we have to select `atT(bayestopt_.smoother_var_list(i),:)` instead of `atT(i,:)` if `bayestopt_.smoother_var_list` is not equal to `bayestopt_.smoother_saved_var_list`, which happens with `selected_variables_only`
In master the same problem has been ported to `write_smoother_results`
@MichelJuillard @stepan-a Should we try to fix this or should we get rid of the `selected_variables_only` option?
https://git.dynare.org/Dynare/dynare/issues/1157Save kurtosis and skewness when using simulated moments2019-06-19T15:37:51ZJohannes Pfeifer Save kurtosis and skewness when using simulated momentshttps://git.dynare.org/Dynare/dynare/issues/1154Investigate crash of Octave under Windows2019-06-19T15:37:51ZJohannes Pfeifer Investigate crash of Octave under WindowsThere are two problems with the following mod-file under Octave
```
var ygap pinf i u p a r_nat;
varexo eu ea;
parameters csigma cbeta crhou ckappa cweightygap crpinf cry clambda cepsilon ctheta cphi crhoa calfa;
csigma = 1.0;
cbeta = 0.99;
crhou = 0.8 ;
cweightygap = .1;
crpinf = 1.5;
cry = 0.125;
cepsilon = 6;
ctheta = 2/3;
calfa = 0.33;
cphi = 1;
clambda = (1-ctheta)*(1-ctheta*cbeta)/ctheta *(1-calfa)/(1-calfa+calfa*cepsilon);
ckappa = clambda*(csigma+(cphi+calfa)/(1-calfa));
calphax = ckappa/cepsilon;
crhoa =0.9;
model(linear);
ygap = ygap(+1) - (1/csigma)*(i-pinf(+1) - r_nat);
pinf = cbeta*pinf(+1) + ckappa*ygap + u;
u = crhou*u(-1) + eu;
p=p(-1)+pinf;
// the exogenous processes for productivity
a = crhoa*a(-1) + ea;
// the process for the natural rate can be derived from the flexible economy solution
r_nat = csigma*(1+cphi)/((1-calfa)*csigma+cphi+calfa)*(crhoa-1)*a;
end;
shocks;
var eu; stderr 1;
var ea; stderr 1;
end;
// ramsey
planner_objective(ckappa/cepsilon*ygap^2+pinf^2);
ramsey_policy(planner_discount=0.99,order=1,instruments=(i),irf=12);
```
First of all, when no mex-files are present, `mjdgges.m` returns very different results than Matlab or the mex-file. While Octave then returns a rank failure, Matlab finds a small, but OK condition number and continues.
Second, when using the mex-files, Dynare crashes Octave 3.8.2 when computing theoretical moments. The culprit is the call to `ordschur.oct` in `lyap_symm`. The attached files allow to reproduce the error:
[crash_octave.zip](https://github.com/DynareTeam/dynare/files/193860/crash_octave.zip)
My guess is that the problem stems from `p`, which has a unit root and therefore non-finite second moments. This seems to be incorrectly handled.
There are two problems with the following mod-file under Octave
```
var ygap pinf i u p a r_nat;
varexo eu ea;
parameters csigma cbeta crhou ckappa cweightygap crpinf cry clambda cepsilon ctheta cphi crhoa calfa;
csigma = 1.0;
cbeta = 0.99;
crhou = 0.8 ;
cweightygap = .1;
crpinf = 1.5;
cry = 0.125;
cepsilon = 6;
ctheta = 2/3;
calfa = 0.33;
cphi = 1;
clambda = (1-ctheta)*(1-ctheta*cbeta)/ctheta *(1-calfa)/(1-calfa+calfa*cepsilon);
ckappa = clambda*(csigma+(cphi+calfa)/(1-calfa));
calphax = ckappa/cepsilon;
crhoa =0.9;
model(linear);
ygap = ygap(+1) - (1/csigma)*(i-pinf(+1) - r_nat);
pinf = cbeta*pinf(+1) + ckappa*ygap + u;
u = crhou*u(-1) + eu;
p=p(-1)+pinf;
// the exogenous processes for productivity
a = crhoa*a(-1) + ea;
// the process for the natural rate can be derived from the flexible economy solution
r_nat = csigma*(1+cphi)/((1-calfa)*csigma+cphi+calfa)*(crhoa-1)*a;
end;
shocks;
var eu; stderr 1;
var ea; stderr 1;
end;
// ramsey
planner_objective(ckappa/cepsilon*ygap^2+pinf^2);
ramsey_policy(planner_discount=0.99,order=1,instruments=(i),irf=12);
```
First of all, when no mex-files are present, `mjdgges.m` returns very different results than Matlab or the mex-file. While Octave then returns a rank failure, Matlab finds a small, but OK condition number and continues.
Second, when using the mex-files, Dynare crashes Octave 3.8.2 when computing theoretical moments. The culprit is the call to `ordschur.oct` in `lyap_symm`. The attached files allow to reproduce the error:
[crash_octave.zip](https://github.com/DynareTeam/dynare/files/193860/crash_octave.zip)
My guess is that the problem stems from `p`, which has a unit root and therefore non-finite second moments. This seems to be incorrectly handled.
5.0https://git.dynare.org/Dynare/dynare/issues/1150derivation with respect to the parameters2019-06-19T15:37:52ZMichelJuillardderivation with respect to the parametersWhen modifying <fname>_static.m in order to address problems with auxiliary variables (see #1133), I realized that the creation of <fname>_params_derivs.m and the code for analytical derivatives of the likelihood function assume that the static model is the static version of the <fname>_dynamic, equation by equation.
This is not obvious in the preprocessor where the static model is stored and handled in a different tree and it stops me to find an efficient solution to the computation of the steady state of auxiliary variables.
For this reason, I will introduce two files for the computation of the derivatives with respect to the parameters: <fname>_params_derivs_static and <fname>_derivs_dynamic
I will also change all calling sequences throughout the code
When modifying <fname>_static.m in order to address problems with auxiliary variables (see #1133), I realized that the creation of <fname>_params_derivs.m and the code for analytical derivatives of the likelihood function assume that the static model is the static version of the <fname>_dynamic, equation by equation.
This is not obvious in the preprocessor where the static model is stored and handled in a different tree and it stops me to find an efficient solution to the computation of the steady state of auxiliary variables.
For this reason, I will introduce two files for the computation of the derivatives with respect to the parameters: <fname>_params_derivs_static and <fname>_derivs_dynamic
I will also change all calling sequences throughout the code
4.5MichelJuillardMichelJuillardhttps://git.dynare.org/Dynare/dynare/issues/1149Harmonize output of objective functions passed to minimizers2019-06-19T15:37:52ZJohannes Pfeifer Harmonize output of objective functions passed to minimizersPrerequisite for eliminating the global variable `objective_function_penalty_base` (#1051) and to avoid introducing another layer of functions as in reverted commit https://github.com/DynareTeam/dynare/commit/1ad8df4635d99ba775e22f5693bf18c2cbb6c0aa (see also the discussion there)
Prerequisite for eliminating the global variable `objective_function_penalty_base` (#1051) and to avoid introducing another layer of functions as in reverted commit https://github.com/DynareTeam/dynare/commit/1ad8df4635d99ba775e22f5693bf18c2cbb6c0aa (see also the discussion there)
4.5Johannes Pfeifer Johannes Pfeifer 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/1133auxiliary variables in steady state and static model2019-06-19T15:37:52ZMichelJuillardauxiliary variables in steady state and static modelCurrently, in static model and set_auxiliary_variables.m, auxiliary variables may appear in the RHS of equations. This is problematic for two reasons:
1. assignments may not be recurice in set_auxiliary_variables.m which leads to errors
2. <fname>_static.m may not be solved independently from set_auxiliary_variables.m
In the static deterministic model, any auxiliary variable, except Lagrange multipliers for Ramsey policy, can be replaced with an expression using only original variables.
In the preprocessor, I want to rewrite <fname>_static.m and <fname>_set_auxiliary_variables.m along these lines.
I expect this changes to solve #1119 and #633
Currently, in static model and set_auxiliary_variables.m, auxiliary variables may appear in the RHS of equations. This is problematic for two reasons:
1. assignments may not be recurice in set_auxiliary_variables.m which leads to errors
2. <fname>_static.m may not be solved independently from set_auxiliary_variables.m
In the static deterministic model, any auxiliary variable, except Lagrange multipliers for Ramsey policy, can be replaced with an expression using only original variables.
In the preprocessor, I want to rewrite <fname>_static.m and <fname>_set_auxiliary_variables.m along these lines.
I expect this changes to solve #1119 and #633
4.5MichelJuillardMichelJuillardhttps://git.dynare.org/Dynare/dynare/issues/1128Extended Path disagreeing with OccBin and DynareOBC on linear models2019-06-19T15:37:52ZTom HoldenExtended Path disagreeing with OccBin and DynareOBC on linear modelsDynareOBC contains tests which solve the same otherwise linear model with the Extended Path, OccBin, and with DynareOBC. OccBin and DynareOBC agree (up to the order of 10^(-8)), but the extended path is way off (e.g. responses 10 times larger).
(It's just possible that there's something up with my version of Dynare, but the fact that running `git diff upstream/master -- matlab/ep/` produces no output suggests that this probably isn't the problem at least.)
The tests are in this folder: https://github.com/tholden/dynareOBC/tree/master/Tests/ComparisonOfPerfectForesightSolutionsForLinearModels
You could just compare OccBin vs ExtendedPath by commenting out the appropriate lines of RunAllAndCompare.m, saving you the trouble of setting up DynareOBC.
DynareOBC contains tests which solve the same otherwise linear model with the Extended Path, OccBin, and with DynareOBC. OccBin and DynareOBC agree (up to the order of 10^(-8)), but the extended path is way off (e.g. responses 10 times larger).
(It's just possible that there's something up with my version of Dynare, but the fact that running `git diff upstream/master -- matlab/ep/` produces no output suggests that this probably isn't the problem at least.)
The tests are in this folder: https://github.com/tholden/dynareOBC/tree/master/Tests/ComparisonOfPerfectForesightSolutionsForLinearModels
You could just compare OccBin vs ExtendedPath by commenting out the appropriate lines of RunAllAndCompare.m, saving you the trouble of setting up DynareOBC.
https://git.dynare.org/Dynare/dynare/issues/1125make xref more efficient, write to .m file2019-06-19T15:37:52ZHoutan Bastanimake xref more efficient, write to .m fileFrom @MichelJuillard
For large models it is really slow. I think that we should
1) add an Dynare option to compute them and write them in `*.m` file
(unless it is required for a particular computation, but it is not yet
the case)
2) change the Matlab code: `{end+1}` is very elegant but very inefficient
because Matlab makes memory allocations several times. It is better to
initialize first the cellarray and use an index for the assignment. The
size is `M_.endo_nbr` and `M_.eq_nbr`
From @MichelJuillard
For large models it is really slow. I think that we should
1) add an Dynare option to compute them and write them in `*.m` file
(unless it is required for a particular computation, but it is not yet
the case)
2) change the Matlab code: `{end+1}` is very elegant but very inefficient
because Matlab makes memory allocations several times. It is better to
initialize first the cellarray and use an index for the assignment. The
size is `M_.endo_nbr` and `M_.eq_nbr`
4.5Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/issues/1119Investigate potential bug introduced by 15716124fa6f061ca21e8f6c5a4907a4b0c525622019-06-19T15:37:52ZHoutan BastaniInvestigate potential bug introduced by 15716124fa6f061ca21e8f6c5a4907a4b0c52562The change introduced in 15716124fa6f061ca21e8f6c5a4907a4b0c52562 was meant to fix the existing bug in `aux_equations` that did not recursively substitute variables in `aux_equations` even though they were substituted in `equations`. We must see if this commit introduced a bug or if there is a bug in the way ramsey code deals with auxiliary equations.
@JohannesPfeifer pointed this out due to the failure of `optimal_policy/Ramsey/ramsey_ex_aux.mod` introduced by this commit
The change introduced in 15716124fa6f061ca21e8f6c5a4907a4b0c52562 was meant to fix the existing bug in `aux_equations` that did not recursively substitute variables in `aux_equations` even though they were substituted in `equations`. We must see if this commit introduced a bug or if there is a bug in the way ramsey code deals with auxiliary equations.
@JohannesPfeifer pointed this out due to the failure of `optimal_policy/Ramsey/ramsey_ex_aux.mod` introduced by this commit
4.5MichelJuillardMichelJuillardhttps://git.dynare.org/Dynare/dynare/issues/1121Fix compilation flags in the build system2019-06-19T15:37:52ZStéphane Adjemianstepan@dynare.orgFix compilation flags in the build systemCompilation flags (`CFLAGS` and `CXXFLAGS`) specified with the `configure` script are not passed correctly when building the mex files (the preprocessor and dynare++ honour the flags). So the mex files are always compiled with debug symbols and it is not possible to use more aggressive optimizations (ie `-O3`).
Compilation flags (`CFLAGS` and `CXXFLAGS`) specified with the `configure` script are not passed correctly when building the mex files (the preprocessor and dynare++ honour the flags). So the mex files are always compiled with debug symbols and it is not possible to use more aggressive optimizations (ie `-O3`).
4.5Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/issues/1117Get rid of globals in make_ex_2019-06-19T15:37:52ZJohannes Pfeifer Get rid of globals in make_ex_Their presence creates a bunch of issues. In dfc89df6a8f5ff0f94c515934caf576088f5c5f6 we added a call to `make_ex_` to make the `tests/forecast/Hansen_exo_det_forecast.mod` run. But then 105100c7fefcf3610214a5bb8c6970098e8cb9aa eliminated the globals from `dyn_forecast`, splitting the workspace of globals used within `dyn_forecast` from the one set by `make_ex_`, thereby breaking the unit test.
Their presence creates a bunch of issues. In dfc89df6a8f5ff0f94c515934caf576088f5c5f6 we added a call to `make_ex_` to make the `tests/forecast/Hansen_exo_det_forecast.mod` run. But then 105100c7fefcf3610214a5bb8c6970098e8cb9aa eliminated the globals from `dyn_forecast`, splitting the workspace of globals used within `dyn_forecast` from the one set by `make_ex_`, thereby breaking the unit test.
https://git.dynare.org/Dynare/dynare/issues/1113Make Dynare compatible with Octave 4.22019-06-19T15:37:52ZJohannes Pfeifer Make Dynare compatible with Octave 4.2Requires among other things dealing with the mex-files, see http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=7570
Requires among other things dealing with the mex-files, see http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=7570
5.0MichelJuillardMichelJuillardhttps://git.dynare.org/Dynare/dynare/issues/1111is tests/reporting/example1.mod syntax up to date? Is the test necessary?2019-06-19T15:37:52ZHoutan Bastaniis tests/reporting/example1.mod syntax up to date? Is the test necessary?4.5Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/issues/1110make substitutions in aux_equations the same way as in equations in DynamicMo...2019-06-19T15:37:52ZHoutan Bastanimake substitutions in aux_equations the same way as in equations in DynamicModel::substituteLeadLagInternalcurrently, `aux_equations` and the auxiliary equations in `equations` are out of sync
currently, `aux_equations` and the auxiliary equations in `equations` are out of sync
4.5Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/issues/1106Make treatment of delimiters in missing/strjoin compatible with Matlab2019-06-19T15:37:52ZJohannes Pfeifer Make treatment of delimiters in missing/strjoin compatible with MatlabThe Dynare version returns for `strjoin({'aa','bb'},'\n')`
`ans =aa\nbb`
while Matlab returns
```
ans =
aa
bb
```
The same holds for other delimiters like the tabulator `\t` that are treated like literal characters.
The Dynare version returns for `strjoin({'aa','bb'},'\n')`
`ans =aa\nbb`
while Matlab returns
```
ans =
aa
bb
```
The same holds for other delimiters like the tabulator `\t` that are treated like literal characters.
Johannes Pfeifer Johannes Pfeifer https://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/1092Allow changing planner_discount in mod-file (preprocessor restriction)2019-06-19T15:37:52ZJohannes Pfeifer Allow changing planner_discount in mod-file (preprocessor restriction)See the discussion on the mailing list on 31/08/2015. This problem crashes the `Gali_discretion.mod` unit test. My proposal is:
Treat the planner_discount option like any other option (or parameter for that matter) and allow resetting it via the same statement later on. If a warning is needed, I would provide a warning that the planner_discount has been updated. But I don't really see the need for this warning. Changing parameters is common.
See the discussion on the mailing list on 31/08/2015. This problem crashes the `Gali_discretion.mod` unit test. My proposal is:
Treat the planner_discount option like any other option (or parameter for that matter) and allow resetting it via the same statement later on. If a warning is needed, I would provide a warning that the planner_discount has been updated. But I don't really see the need for this warning. Changing parameters is common.
Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/issues/1094Check setting of bayestopt_ in set_prior.m2019-06-19T15:37:52ZJohannes Pfeifer Check setting of bayestopt_ in set_prior.mIn master, `ls2003.mod` crashes, because `set_prior.m` is called, which overwrites `bayestopt_` globally. The main culprit is the bottom line:
```
% Put bayestopt_ in matlab's workspace
assignin('base','bayestopt_',bayestopt_);
```
I don't understand why we have `set_prior.m` returning `bayestopt_` as a function output and simultaneously setting it as a global variable. I would propose getting rid of the above statement.
In master, `ls2003.mod` crashes, because `set_prior.m` is called, which overwrites `bayestopt_` globally. The main culprit is the bottom line:
```
% Put bayestopt_ in matlab's workspace
assignin('base','bayestopt_',bayestopt_);
```
I don't understand why we have `set_prior.m` returning `bayestopt_` as a function output and simultaneously setting it as a global variable. I would propose getting rid of the above statement.
https://git.dynare.org/Dynare/dynare/issues/1090Save marginal data density from BVAR2019-06-19T15:37:53ZJohannes Pfeifer Save marginal data density from BVARCurrently, it is computed and displayed, but not stored. See http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=7365
Currently, it is computed and displayed, but not stored. See http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=7365
https://git.dynare.org/Dynare/dynare/issues/1081Add Chandrasekhar Recursion Kalman Filter2019-06-19T15:37:53ZJohannes Pfeifer Add Chandrasekhar Recursion Kalman FilterAs discussed during the 2015 Dynare conference, this might be a nice addition for larger models. See
Herbst (2015): "Using the “Chandrasekhar Recursions” for Likelihood Evaluation of DSGE Models", Comput Econ (2015) 45:693–705
As discussed during the 2015 Dynare conference, this might be a nice addition for larger models. See
Herbst (2015): "Using the “Chandrasekhar Recursions” for Likelihood Evaluation of DSGE Models", Comput Econ (2015) 45:693–705
5.0https://git.dynare.org/Dynare/dynare/issues/1077Integrate doubling algorithm into lyapunov_symm2019-06-19T15:37:53ZJohannes Pfeifer Integrate doubling algorithm into lyapunov_symmFollowing #988 and the discussions at the 2015 Dynare conference, we should integrate `disclyap_fast.m` into `lyapunov_symm` to have one solver only. The question is whether we want to integrate this as a call to `disclyap_fast.m`as an external function or whether to make `disclyap_fast.m` a nested function within `lyapunov_symm`. I would prefer the latter, because it makes the function with the doubling algorithm reusable as a standalone in the way Herbst (2015) and Schmitt-Grohé/Uribe already use it.
When doing this, we also need to discuss the option handling as we currently do not pass the doubling tolerance to `lyapunov_symm`. Currently, we pass `lyapunov_fixed_point_tol`. I would propose to use this input argument as the tolerance criterion if the doubling algorithm is selected.
Following #988 and the discussions at the 2015 Dynare conference, we should integrate `disclyap_fast.m` into `lyapunov_symm` to have one solver only. The question is whether we want to integrate this as a call to `disclyap_fast.m`as an external function or whether to make `disclyap_fast.m` a nested function within `lyapunov_symm`. I would prefer the latter, because it makes the function with the doubling algorithm reusable as a standalone in the way Herbst (2015) and Schmitt-Grohé/Uribe already use it.
When doing this, we also need to discuss the option handling as we currently do not pass the doubling tolerance to `lyapunov_symm`. Currently, we pass `lyapunov_fixed_point_tol`. I would propose to use this input argument as the tolerance criterion if the doubling algorithm is selected.
5.0https://git.dynare.org/Dynare/dynare/issues/1076Add preprocessor interface for prior_posterior_function2019-06-19T15:37:53ZJohannes Pfeifer Add preprocessor interface for prior_posterior_functionSee original PR https://github.com/DynareTeam/dynare/pull/871
See original PR https://github.com/DynareTeam/dynare/pull/871
4.5Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/issues/1073move test suite timing to bokeh2019-06-19T15:37:54ZHoutan Bastanimove test suite timing to bokeh- store commit number + date of test run
- two y-axes : 1 for matlab test, 1 for octave
- store commit number + date of test run
- two y-axes : 1 for matlab test, 1 for octave
4.5Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/issues/1074test suite timing: when a test is run more than once on a given day, keep the...2019-06-19T15:37:54ZHoutan Bastanitest suite timing: when a test is run more than once on a given day, keep the last run4.5Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/issues/1072fix test suite on OS X2019-06-19T15:37:54ZHoutan Bastanifix test suite on OS XHoutan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/issues/1069prevent test suite from failing when a call to octave/matlab fails2019-06-19T15:37:54ZHoutan Bastaniprevent test suite from failing when a call to octave/matlab failsAdd a `-` in front of the calls to octave/matlab. Then add a script afterward that will test for the existence of the `.trs` file and, if it doesn't exist, create it with some information that will allow it to be separated later in the email
Add a `-` in front of the calls to octave/matlab. Then add a script afterward that will test for the existence of the `.trs` file and, if it doesn't exist, create it with some information that will allow it to be separated later in the email
4.5Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/issues/1070un-revert 48257450475c306c03fdcbea9901bb3ab9fb8293 and 62b1c85fd4638cb01435d3...2019-06-19T15:37:54ZHoutan Bastaniun-revert 48257450475c306c03fdcbea9901bb3ab9fb8293 and 62b1c85fd4638cb01435d35ed2458a538d897d2fThey were reverted to simplify the debugging of the test suite due to the upgrade to Debian Jessie
They were reverted to simplify the debugging of the test suite due to the upgrade to Debian Jessie
4.5Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/issues/1066Skip dynare initialization when run with noclearall when dynare has previousl...2019-06-19T15:37:54ZTom HoldenSkip dynare initialization when run with noclearall when dynare has previously runThe below is a feature request which seems particularly pertinent in light of https://github.com/DynareTeam/dynare/issues/1057 :
In code that calls dynare repeatedly with noclearall, the time spent in Dynare's initialization can be a non-trivial contribution.
Can we set a global flag when Dynare is initialized (e.g. paths set, mex files found, etc.), and skip as much as possible on subsequent runs?
The below is a feature request which seems particularly pertinent in light of https://github.com/DynareTeam/dynare/issues/1057 :
In code that calls dynare repeatedly with noclearall, the time spent in Dynare's initialization can be a non-trivial contribution.
Can we set a global flag when Dynare is initialized (e.g. paths set, mex files found, etc.), and skip as much as possible on subsequent runs?
5.0Stéphane Adjemianstepan@dynare.orgStéphane Adjemianstepan@dynare.orghttps://git.dynare.org/Dynare/dynare/issues/1063Make output of dsge_var_likelihood accessible2019-06-19T15:37:54ZJohannes Pfeifer Make output of dsge_var_likelihood accessibleSee the discussions in http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=7315 and http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=2920
See the discussions in http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=7315 and http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=2920
5.0https://git.dynare.org/Dynare/dynare/issues/1065factorizing posterior samplers + inclusion of slice sampler2019-06-19T15:37:54ZMarco Rattofactorizing posterior samplers + inclusion of slice samplerI am going to make a pull request from by personal branch
https://github.com/rattoma/dynare/tree/slice
the aim is to add a new posterior sampler, SLICE, but also to make it easier to add further new ones.
There is a bunch of common codes in random walk, independent, TARB, etc. and I did not want to follow that route.
So I wrote, adapting from random walk algorithm, a new general set of routines
`posterior_sampler_*`
that factorizes the iteration of individual samplers, but the rest of the engine is common: initialization, parallelization, bars, `load_mh_file` etc...
The current implementation fully integrates:
- random walk MH
- independent MH
- slice
It also contains a quick fix for TARB but the latter could be easily fully integrated in the new framework.
An open issue concerns adaptive_metropolis_hastings.m [last commit in 2013], which cannot be easily integrated, so I trapped it in dynare_estimation_1.m keeping the old framework.
Concerning pre-processor provisions, this commit would require:
1) enable slice as new sampler method:
`options_.posterior_sampling_method = 'slice';`
2) enable a form of flexible method specific options, along the lines of optimizers options. would this be possible? To explain better:
I added a new option field `options_.posterior_sampler_options` that can contain method specific options. one could specify a syntax like
`sampler_options=(NAME, VALUE, etc..)`
with name/value pairs. These will be stored as fields of
`options_.posterior_sampler_options`
So the command
`estimation(posterior_sampling_method = slice, sampler_options=('rotated',1), ...)`
would trigger
`options_.posterior_sampler_options.rotated = 1`
what do you think?
I am going to make a pull request from by personal branch
https://github.com/rattoma/dynare/tree/slice
the aim is to add a new posterior sampler, SLICE, but also to make it easier to add further new ones.
There is a bunch of common codes in random walk, independent, TARB, etc. and I did not want to follow that route.
So I wrote, adapting from random walk algorithm, a new general set of routines
`posterior_sampler_*`
that factorizes the iteration of individual samplers, but the rest of the engine is common: initialization, parallelization, bars, `load_mh_file` etc...
The current implementation fully integrates:
- random walk MH
- independent MH
- slice
It also contains a quick fix for TARB but the latter could be easily fully integrated in the new framework.
An open issue concerns adaptive_metropolis_hastings.m [last commit in 2013], which cannot be easily integrated, so I trapped it in dynare_estimation_1.m keeping the old framework.
Concerning pre-processor provisions, this commit would require:
1) enable slice as new sampler method:
`options_.posterior_sampling_method = 'slice';`
2) enable a form of flexible method specific options, along the lines of optimizers options. would this be possible? To explain better:
I added a new option field `options_.posterior_sampler_options` that can contain method specific options. one could specify a syntax like
`sampler_options=(NAME, VALUE, etc..)`
with name/value pairs. These will be stored as fields of
`options_.posterior_sampler_options`
So the command
`estimation(posterior_sampling_method = slice, sampler_options=('rotated',1), ...)`
would trigger
`options_.posterior_sampler_options.rotated = 1`
what do you think?
https://git.dynare.org/Dynare/dynare/issues/1059Make names of model-local variables TeX-compatible2019-06-19T15:37:54ZJohannes Pfeifer Make names of model-local variables TeX-compatibleIn particular, replace underscores. See https://github.com/DynareTeam/dynare/issues/263#issuecomment-139540237
Potentially, we might allow defining a TeX-name for them.
In particular, replace underscores. See https://github.com/DynareTeam/dynare/issues/263#issuecomment-139540237
Potentially, we might allow defining a TeX-name for them.
4.5Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/issues/1058Make Dynare compatible with Matlab2015b2019-06-19T15:37:54ZJohannes Pfeifer Make Dynare compatible with Matlab2015bSee https://github.com/DynareTeam/dynare/commit/1a3d8d0b26a398c60221cdceb234036140d8fd4e, 6a17fe5de3e9834da01b6ad10abd891cff35be22, and b4a8ad8aa4b992c49638c90207871a9feaa18c3c for previous version.
See https://github.com/DynareTeam/dynare/commit/1a3d8d0b26a398c60221cdceb234036140d8fd4e, 6a17fe5de3e9834da01b6ad10abd891cff35be22, and b4a8ad8aa4b992c49638c90207871a9feaa18c3c for previous version.
https://git.dynare.org/Dynare/dynare/issues/1054argument steadystate_check_flag is ignored in evaluate_steady_state2019-06-19T15:37:54ZMichelJuillardargument steadystate_check_flag is ignored in evaluate_steady_stateMichelJuillardMichelJuillardhttps://git.dynare.org/Dynare/dynare/issues/1057Rethink default clear all to improve compatibility with Matlab 2015b2019-06-19T15:37:54ZJohannes Pfeifer Rethink default clear all to improve compatibility with Matlab 2015bWith Matlab 2015b the default `clear all` statement interferes with the new just-in-time compiler, resulting in many warnings and poor performance.
We may want to get rid of this clear all.
With Matlab 2015b the default `clear all` statement interferes with the new just-in-time compiler, resulting in many warnings and poor performance.
We may want to get rid of this clear all.
Stéphane Adjemianstepan@dynare.orgStéphane Adjemianstepan@dynare.orghttps://git.dynare.org/Dynare/dynare/issues/1051Eliminate the global variable objective_function_penalty_base2019-06-19T15:37:54ZTom HoldenEliminate the global variable objective_function_penalty_baseThis causes problems when the estimation function is evaluated in parallel, using fmincon's 'UseParallel','always' or similar. Further problems with parallel objectives are given in this issue: https://github.com/DynareTeam/dseries/issues/10
This causes problems when the estimation function is evaluated in parallel, using fmincon's 'UseParallel','always' or similar. Further problems with parallel objectives are given in this issue: https://github.com/DynareTeam/dseries/issues/10
4.5Johannes Pfeifer Johannes Pfeifer https://git.dynare.org/Dynare/dynare/issues/1053mode_compute=5 breaks computing total execution time2019-06-19T15:37:54ZMichelJuillardmode_compute=5 breaks computing total execution timemode_compute=5 resets maybe time counters with tic and toc. To be checked
mode_compute=5 resets maybe time counters with tic and toc. To be checked
MichelJuillardMichelJuillardhttps://git.dynare.org/Dynare/dynare/issues/1047Make Ramsey and discretionary_policy mutually exclusive via preprocessor2019-06-19T15:37:54ZJohannes Pfeifer Make Ramsey and discretionary_policy mutually exclusive via preprocessorFollows discussion on mailing list on 31/08/2015.
Follows discussion on mailing list on 31/08/2015.
4.5Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/issues/1048Eliminate remaining randomness from estimation routines2019-06-19T15:37:54ZJohannes Pfeifer Eliminate remaining randomness from estimation routinesRelated to http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=7243&p=21224#p21224
There still seem to be elements where we do not make sure that estimation becomes "deterministic". For example, we only reset the seed in `metropolis_hastings_initialization` after we have initialized the chains via
```
candidate = rand_multivariate_normal( transpose(xparam1), d * options_.mh_init_scale, npar);
```
thereby introducing an element of randomness. This seems to be particularly relevant if optimizers are used that rely on random numbers.
Related to http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=7243&p=21224#p21224
There still seem to be elements where we do not make sure that estimation becomes "deterministic". For example, we only reset the seed in `metropolis_hastings_initialization` after we have initialized the chains via
```
candidate = rand_multivariate_normal( transpose(xparam1), d * options_.mh_init_scale, npar);
```
thereby introducing an element of randomness. This seems to be particularly relevant if optimizers are used that rely on random numbers.
https://git.dynare.org/Dynare/dynare/issues/1041Save planner objective after running discretionary_policy2019-06-19T15:37:54ZJohannes Pfeifer Save planner objective after running discretionary_policyFor some reason `discretionary_policy.m` has the commented line
```
%oo_ = evaluate_planner_objective(oo_.dr,M_,oo_,options_);
```
Is there a reason we do not simply add
```
oo_.planner_objective_value = evaluate_planner_objective(M_,options_,oo_);
```
to the function to actually save the objective function value as for Ramey?
For some reason `discretionary_policy.m` has the commented line
```
%oo_ = evaluate_planner_objective(oo_.dr,M_,oo_,options_);
```
Is there a reason we do not simply add
```
oo_.planner_objective_value = evaluate_planner_objective(M_,options_,oo_);
```
to the function to actually save the objective function value as for Ramey?
https://git.dynare.org/Dynare/dynare/issues/1035Add option to save kernel density for posterior objects2019-06-19T15:37:54ZJohannes Pfeifer Add option to save kernel density for posterior objectsThis allows for example getting the posterior density of forecasts.
It simply requires adjusting `pm3.m` to save the objects that can already be computed via `posterior_moments`.
I would propose to call the option `posterior_kernel_density` and save it to `options_.estimation.posterior_kernel_density.indicator=1`
This allows for example getting the posterior density of forecasts.
It simply requires adjusting `pm3.m` to save the objects that can already be computed via `posterior_moments`.
I would propose to call the option `posterior_kernel_density` and save it to `options_.estimation.posterior_kernel_density.indicator=1`
4.5Johannes Pfeifer Johannes Pfeifer https://git.dynare.org/Dynare/dynare/issues/1039@#include should pull in mod files off the MATLAB path, not just the current ...2019-06-19T15:37:54ZTom Holden@#include should pull in mod files off the MATLAB path, not just the current folderTo enable @#include to be easily used with libraries of utilities e.g. https://github.com/tholden/DynareTransformationEngine , it needs to be able to include MOD files that are not in the current folder, and are instead somewhere in the MATLAB path. Copying and pasting is both messy and unreliable.
To enable @#include to be easily used with libraries of utilities e.g. https://github.com/tholden/DynareTransformationEngine , it needs to be able to include MOD files that are not in the current folder, and are instead somewhere in the MATLAB path. Copying and pasting is both messy and unreliable.
Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/issues/1034Add capacities for rolling window forecasts2019-06-19T15:37:54ZJohannes Pfeifer Add capacities for rolling window forecastsCurrently, we only support recursive forecasting where the time window, on which the model is estimated, expands.
Necessary steps:
1. Allow `estimation` option `first_obs` to take vector like `nobs` (with the same consistency checks)
2. Adjust `dynare_estimation` to not either set `options_.nobs = nobs(i);` or `options_.first_obs=first_obs(i)` and add check that makes them mutually exclusive.
The only problem is returning the results. Currently, `dynare_estimation` returns `oo_recursive`. We can either store the rolling window estimation in the same structure or let the preprocessor assign the results to either `oo_recursive` or `oo_rolling` depending on whether `nobs` or `first_obs` is more than a scalar. In this case, the preprocessor must also do the check that either rolling or recursive estimation can be requested, but not both.
Currently, we only support recursive forecasting where the time window, on which the model is estimated, expands.
Necessary steps:
1. Allow `estimation` option `first_obs` to take vector like `nobs` (with the same consistency checks)
2. Adjust `dynare_estimation` to not either set `options_.nobs = nobs(i);` or `options_.first_obs=first_obs(i)` and add check that makes them mutually exclusive.
The only problem is returning the results. Currently, `dynare_estimation` returns `oo_recursive`. We can either store the rolling window estimation in the same structure or let the preprocessor assign the results to either `oo_recursive` or `oo_rolling` depending on whether `nobs` or `first_obs` is more than a scalar. In this case, the preprocessor must also do the check that either rolling or recursive estimation can be requested, but not both.
4.5Johannes Pfeifer Johannes Pfeifer https://git.dynare.org/Dynare/dynare/issues/1033typo in dsge_likelihood.m2019-06-19T15:37:56ZTom Holdentypo in dsge_likelihood.mLines 366 and 480 of dsge_likelihood.m are as follows:
```
switch DynareOptions.lik_init
...
case options_.lik_init == 5 % Old diffuse Kalman filter only for the non stationary variables
```
I presume the `options_.lik_init ==` should not be there? `options_` is no longer even defined in DsgeLikelihood.m, so if none of the previous cases have been matched, a MATLAB error will be generated when MATLAB attempts to access a field of the non-existent structure.
Lines 366 and 480 of dsge_likelihood.m are as follows:
```
switch DynareOptions.lik_init
...
case options_.lik_init == 5 % Old diffuse Kalman filter only for the non stationary variables
```
I presume the `options_.lik_init ==` should not be there? `options_` is no longer even defined in DsgeLikelihood.m, so if none of the previous cases have been matched, a MATLAB error will be generated when MATLAB attempts to access a field of the non-existent structure.
https://git.dynare.org/Dynare/dynare/issues/1028Transform M_.aux_vars.eq_nbr from char to double2019-06-19T15:37:56ZJohannes Pfeifer Transform M_.aux_vars.eq_nbr from char to doubleFor some reason, the equation number is stored by the preprocessor as a character, leading to problems in `display_problematic_vars_Jacobian.m`
For some reason, the equation number is stored by the preprocessor as a character, leading to problems in `display_problematic_vars_Jacobian.m`
4.5Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/issues/1026Investigate memory issue of k_order dll (Dynare++)2019-06-19T15:37:56ZJohannes Pfeifer Investigate memory issue of k_order dll (Dynare++)See http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=7155. Even with 32GB RAM, it crashes with
`terminate called after throwing an instance of 'std::bad_alloc'
what(): std::bad_alloc`
which seems weird. This may also be related to #612
See http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=7155. Even with 32GB RAM, it crashes with
`terminate called after throwing an instance of 'std::bad_alloc'
what(): std::bad_alloc`
which seems weird. This may also be related to #612
MichelJuillardMichelJuillardhttps://git.dynare.org/Dynare/dynare/issues/1024Save posterior moments even when moments are constant2019-06-19T15:37:56ZJohannes Pfeifer Save posterior moments even when moments are constantIn `covariance_mc_analysis.m` and the like we test whether the moments are constant and, if yes, we store NaN. I don't see the logic of this. All moments are still well-defined (although identical). I would propose to get rid of this check and always store the computed moments.
In `covariance_mc_analysis.m` and the like we test whether the moments are constant and, if yes, we store NaN. I don't see the logic of this. All moments are still well-defined (although identical). I would propose to get rid of this check and always store the computed moments.
https://git.dynare.org/Dynare/dynare/issues/1021Check correctness of DSGE-VAR Wiki2019-06-19T15:37:56ZJohannes Pfeifer Check correctness of DSGE-VAR WikiAccording to Del Negro/Schorfheide (2004), the variance priors and posteriors have degrees of freedom correction with number of estimated parameters in the VAR equation, i.e. variables times lags plus a constant:
```
m*p+1
```
However, http://www.dynare.org/DynareWiki/DsgeVar does not feature a constant in the description, but still uses the same initial improper prior with `m+1` as if a constant would be used (below eqation (21) in DNS (2004)).
Similarly, equations P2 and Q2 of the Wiki use a correction of `-mp-m=-m*(p+1)` suggesting a constant for every variable in each equation.
While the condition for `lambda*T<m(p+1)` coincides with the one below equation (21) in DNS (2004), there is no formal derivation of this condition in DNS . The Wiki motivates this statement by alluding to the fact that we could not use OLS to estimate the equation if `T<m(p+1)`. But this again looks strange as the number of parameters estimated is just `m*p+1`.
According to Del Negro/Schorfheide (2004), the variance priors and posteriors have degrees of freedom correction with number of estimated parameters in the VAR equation, i.e. variables times lags plus a constant:
```
m*p+1
```
However, http://www.dynare.org/DynareWiki/DsgeVar does not feature a constant in the description, but still uses the same initial improper prior with `m+1` as if a constant would be used (below eqation (21) in DNS (2004)).
Similarly, equations P2 and Q2 of the Wiki use a correction of `-mp-m=-m*(p+1)` suggesting a constant for every variable in each equation.
While the condition for `lambda*T<m(p+1)` coincides with the one below equation (21) in DNS (2004), there is no formal derivation of this condition in DNS . The Wiki motivates this statement by alluding to the fact that we could not use OLS to estimate the equation if `T<m(p+1)`. But this again looks strange as the number of parameters estimated is just `m*p+1`.
https://git.dynare.org/Dynare/dynare/issues/1018fix test suite bugs2019-06-19T15:37:56ZHoutan Bastanifix test suite bugsIn email of 6/8/2015 on the dev list, @JohannesPfeifer reported dependencies of the test suite that don't make sense. fix these
In email of 6/8/2015 on the dev list, @JohannesPfeifer reported dependencies of the test suite that don't make sense. fix these
4.5Stéphane Adjemianstepan@dynare.orgStéphane Adjemianstepan@dynare.orghttps://git.dynare.org/Dynare/dynare/issues/1016Clean up setting of options in dynare_sensitivity.m2019-06-19T15:37:56ZJohannes 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.
5.0Marco RattoMarco Rattohttps://git.dynare.org/Dynare/dynare/issues/1013Fix saving of posterior standard deviations2019-06-19T15:37:56ZJohannes Pfeifer Fix saving of posterior standard deviationsSee also http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=7130
When running the MCMC, the `oo_.posterior_std` and `oo_.posterior_mode` fields are based on the posterior mode, not the MCMC. But the manual says they should only be there if `mh_replic>0` but we always write them.
In contrast, `oo_.posterior_variance` is based on the MCMC. However, this field is not documented in the manual at all.
It is also confusing that the MCMC writes only a variance and ML/mode-finder only a standard deviation.
We must decide on a consistent treatment and fix the manual accordingly.
My proposal is: We change the current `oo_.posterior_std` to `oo_.posterior_std_at_mode` to make the meaning explicit and let the MCMC now also write `oo_.posterior_std`. This would be closest to what the manual states as all fields then would have the intended meaning while only adding additional fields. If need be, this would also allow going back to the 4.4 "convention" using the `convert_dyn_45_to_44` utility.
See also http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=7130
When running the MCMC, the `oo_.posterior_std` and `oo_.posterior_mode` fields are based on the posterior mode, not the MCMC. But the manual says they should only be there if `mh_replic>0` but we always write them.
In contrast, `oo_.posterior_variance` is based on the MCMC. However, this field is not documented in the manual at all.
It is also confusing that the MCMC writes only a variance and ML/mode-finder only a standard deviation.
We must decide on a consistent treatment and fix the manual accordingly.
My proposal is: We change the current `oo_.posterior_std` to `oo_.posterior_std_at_mode` to make the meaning explicit and let the MCMC now also write `oo_.posterior_std`. This would be closest to what the manual states as all fields then would have the intended meaning while only adding additional fields. If need be, this would also allow going back to the 4.4 "convention" using the `convert_dyn_45_to_44` utility.
4.5https://git.dynare.org/Dynare/dynare/issues/1012Add one-sided HP filter2019-06-19T15:37:56ZJohannes Pfeifer Add one-sided HP filter#1011 already implemented the interface. Before adding the function, we need to decide whether to simply add it as a function that operates on regular double data like the `sample_hp_filter` or whether we want to make it a function on dseries objects as the `baxter_king_filter.m` of the dseries submodule.
#1011 already implemented the interface. Before adding the function, we need to decide whether to simply add it as a function that operates on regular double data like the `sample_hp_filter` or whether we want to make it a function on dseries objects as the `baxter_king_filter.m` of the dseries submodule.
https://git.dynare.org/Dynare/dynare/issues/1011Add bandpass filter2019-06-19T15:37:56ZJohannes Pfeifer Add bandpass filterAdding a bandpass-filter as in Christiano/Motto/Rostagno seems straightforward.
One issue is `options_.hp_ngrid` which specifies the number of points for the Inverse Fourier Transformation. With a different filter, this option would not be specific to the HP filter anymore. I would suggest renaming it to `ifft_points` and deleting the old option. Obviously, this would break backward compatibility.
@houtanb Could you please give me an option of `stoch_simul` named `bandpass_filter` It should be mutually exclusive with `hp_filter`. If specified as
```
stoch_simul(bandpass_filter)
```
it should map into `options_.bandpass.indicator=1`. If specified as
```
stoch_simul(bandpass_filter=[lowerbound upperbound])
```
it should map into
```
options_.bandpass.indicator=1
options_.bandpass.passband=[lowerbound upperbound]
```
Default values are
```
options_.bandpass.indicator=0;
options_.bandpass.passband=[6 32];
```
Adding a bandpass-filter as in Christiano/Motto/Rostagno seems straightforward.
One issue is `options_.hp_ngrid` which specifies the number of points for the Inverse Fourier Transformation. With a different filter, this option would not be specific to the HP filter anymore. I would suggest renaming it to `ifft_points` and deleting the old option. Obviously, this would break backward compatibility.
@houtanb Could you please give me an option of `stoch_simul` named `bandpass_filter` It should be mutually exclusive with `hp_filter`. If specified as
```
stoch_simul(bandpass_filter)
```
it should map into `options_.bandpass.indicator=1`. If specified as
```
stoch_simul(bandpass_filter=[lowerbound upperbound])
```
it should map into
```
options_.bandpass.indicator=1
options_.bandpass.passband=[lowerbound upperbound]
```
Default values are
```
options_.bandpass.indicator=0;
options_.bandpass.passband=[6 32];
```
4.5Johannes Pfeifer Johannes Pfeifer https://git.dynare.org/Dynare/dynare/issues/1005Dynare 4.3.3 won't compile2019-06-19T15:37:56ZStéphane Adjemianstepan@dynare.orgDynare 4.3.3 won't compile*Created by: mboisson*
I am trying to compile Dynare 4.3.3 for a user (he needs this specific version). I get the following error :
DynareBison.yy:45:36: error: ‘const struct Dynare::parser::stack_symbol_type’ has no member named ‘begin’
(Current).begin = (Rhs)[1].begin; \
^
DynareBison.cc:619:7: note: in expansion of macro ‘YYLLOC_DEFAULT’
YYLLOC_DEFAULT (yylhs.location, slice, yylen);
^
DynareBison.yy:46:36: error: ‘const struct Dynare::parser::stack_symbol_type’ has no member named ‘end’
(Current).end = (Rhs)[N].end; \
^
DynareBison.cc:619:7: note: in expansion of macro ‘YYLLOC_DEFAULT’
YYLLOC_DEFAULT (yylhs.location, slice, yylen);
^
DynareBison.yy:50:52: error: ‘const struct Dynare::parser::stack_symbol_type’ has no member named ‘end’
(Current).begin = (Current).end = (Rhs)[0].end; \
^
DynareBison.cc:619:7: note: in expansion of macro ‘YYLLOC_DEFAULT’
YYLLOC_DEFAULT (yylhs.location, slice, yylen);
^
DynareBison.yy:45:36: error: ‘struct Dynare::parser::stack_symbol_type’ has no member named ‘begin’
(Current).begin = (Rhs)[1].begin; \
^
DynareBison.cc:5399:7: note: in expansion of macro ‘YYLLOC_DEFAULT’
YYLLOC_DEFAULT (error_token.location, yyerror_range, 2);
^
DynareBison.yy:46:36: error: ‘struct Dynare::parser::stack_symbol_type’ has no member named ‘end’
(Current).end = (Rhs)[N].end; \
^
DynareBison.cc:5399:7: note: in expansion of macro ‘YYLLOC_DEFAULT’
YYLLOC_DEFAULT (error_token.location, yyerror_range, 2);
^
DynareBison.yy:50:52: error: ‘struct Dynare::parser::stack_symbol_type’ has no member named ‘end’
(Current).begin = (Current).end = (Rhs)[0].end; \
^
DynareBison.cc:5399:7: note: in expansion of macro ‘YYLLOC_DEFAULT’
YYLLOC_DEFAULT (error_token.location, yyerror_range, 2);
Any idea how to solve this ?
*Created by: mboisson*
I am trying to compile Dynare 4.3.3 for a user (he needs this specific version). I get the following error :
DynareBison.yy:45:36: error: ‘const struct Dynare::parser::stack_symbol_type’ has no member named ‘begin’
(Current).begin = (Rhs)[1].begin; \
^
DynareBison.cc:619:7: note: in expansion of macro ‘YYLLOC_DEFAULT’
YYLLOC_DEFAULT (yylhs.location, slice, yylen);
^
DynareBison.yy:46:36: error: ‘const struct Dynare::parser::stack_symbol_type’ has no member named ‘end’
(Current).end = (Rhs)[N].end; \
^
DynareBison.cc:619:7: note: in expansion of macro ‘YYLLOC_DEFAULT’
YYLLOC_DEFAULT (yylhs.location, slice, yylen);
^
DynareBison.yy:50:52: error: ‘const struct Dynare::parser::stack_symbol_type’ has no member named ‘end’
(Current).begin = (Current).end = (Rhs)[0].end; \
^
DynareBison.cc:619:7: note: in expansion of macro ‘YYLLOC_DEFAULT’
YYLLOC_DEFAULT (yylhs.location, slice, yylen);
^
DynareBison.yy:45:36: error: ‘struct Dynare::parser::stack_symbol_type’ has no member named ‘begin’
(Current).begin = (Rhs)[1].begin; \
^
DynareBison.cc:5399:7: note: in expansion of macro ‘YYLLOC_DEFAULT’
YYLLOC_DEFAULT (error_token.location, yyerror_range, 2);
^
DynareBison.yy:46:36: error: ‘struct Dynare::parser::stack_symbol_type’ has no member named ‘end’
(Current).end = (Rhs)[N].end; \
^
DynareBison.cc:5399:7: note: in expansion of macro ‘YYLLOC_DEFAULT’
YYLLOC_DEFAULT (error_token.location, yyerror_range, 2);
^
DynareBison.yy:50:52: error: ‘struct Dynare::parser::stack_symbol_type’ has no member named ‘end’
(Current).begin = (Current).end = (Rhs)[0].end; \
^
DynareBison.cc:5399:7: note: in expansion of macro ‘YYLLOC_DEFAULT’
YYLLOC_DEFAULT (error_token.location, yyerror_range, 2);
Any idea how to solve this ?
https://git.dynare.org/Dynare/dynare/issues/974Running dynare from inside of a matlab function forces "clear all" behavior.2019-06-19T15:37:56ZStéphane Adjemianstepan@dynare.orgRunning dynare from inside of a matlab function forces "clear all" behavior.*Created by: Ufos92*
Issue: if executing dynare command from inside of a function, all variables that were created inside this function are purged regardless clearall option.
I am not sure, whether this is a dynare bug or a Matlab problem, but may be you at least would like to add this to documentation.
Here is a test-case:
(github does not support upload, so you will have to copypaste the code...)
## ------------ reproduce_bug.m ------------
clear all
% so I create a variable alpha_p for the parameter alpha and try to pass it
% to dynare. The mod file contains following line in the parameter section:
% alpha = alpha_p;
% normal call to dynare:
clear all
alpha_p = 0.33
dynare first_one %noclearall
% doesn't work.
% noclearall option
clear all
alpha_p = 0.33
dynare first_one noclearall
%works
% via function
clear all
run_dynare_param(0.33, 'first_one ', 'noclearall')
% does not work
% via function, but defining alpha_p outside
clear all
alpha_p = 0.33
run_dynare_param(0.33, 'first_one ', 'noclearall')
---
## ------------ run_dynare_param.m ------------
function [out] = run_dynare_param(param_alpha, mod_file, options)
% let's just call dynare with some options and custom parameter alpha
% defaults
if ~exist('options','var')
options = ''
end
% keep dynare output
global M_ options_ oo_
% set alpha
global alpha_p
alpha_p = 0.33
% run dynare
eval(['dynare ', mod_file, ' ', options])
% save and return
out.M = M_;
out.options = options_;
out.oo = oo_;
return
## ------------ first_one.mod ------------
// copypasted from dynare's guide
// ----- Preamble -----
var k l z y c i w r;
varexo e;
parameters beta psi delta alpha rho sigma epsilon;
alpha = alpha_p;
beta = 0.98;
delta = 0.023;
psi = 1.75;
rho = 0.95;
sigma = (0.007/(1-alpha));
epsilon = 10;
// ----- Model -----
model;
(1/c) = beta_(1/c(+1))_(1+r(+1)-delta);
psi_c/(1-l) = w;
c+i = y;
z = rho_z(-1)+e;
y = (k(-1)^alpha)_(exp(z)_l)^(1-alpha);
w = y_((epsilon-1)/epsilon)_(1-alpha)/l;
r = y_((epsilon-1)/epsilon)_alpha/k(-1);
i = k-(1-delta)*k(-1);
end;
// ----- Steady State -----
// almost the exact steady state
initval;
k = 9;
c = 0.7;
l = 0.3;
w = 2.0;
r = 0;
z = 0;
e = 0;
end;
// calculate steady state and set it as the starting point for impulse responce functions
steady;
// Blanchard-Kahn condition check
check;
// ----- Impulse-Responce -----
// shocks
shocks;
var e; stderr 1;
end;
// simulate and plot
// stoch_simul(order = 1) k l z y c i;
*Created by: Ufos92*
Issue: if executing dynare command from inside of a function, all variables that were created inside this function are purged regardless clearall option.
I am not sure, whether this is a dynare bug or a Matlab problem, but may be you at least would like to add this to documentation.
Here is a test-case:
(github does not support upload, so you will have to copypaste the code...)
## ------------ reproduce_bug.m ------------
clear all
% so I create a variable alpha_p for the parameter alpha and try to pass it
% to dynare. The mod file contains following line in the parameter section:
% alpha = alpha_p;
% normal call to dynare:
clear all
alpha_p = 0.33
dynare first_one %noclearall
% doesn't work.
% noclearall option
clear all
alpha_p = 0.33
dynare first_one noclearall
%works
% via function
clear all
run_dynare_param(0.33, 'first_one ', 'noclearall')
% does not work
% via function, but defining alpha_p outside
clear all
alpha_p = 0.33
run_dynare_param(0.33, 'first_one ', 'noclearall')
---
## ------------ run_dynare_param.m ------------
function [out] = run_dynare_param(param_alpha, mod_file, options)
% let's just call dynare with some options and custom parameter alpha
% defaults
if ~exist('options','var')
options = ''
end
% keep dynare output
global M_ options_ oo_
% set alpha
global alpha_p
alpha_p = 0.33
% run dynare
eval(['dynare ', mod_file, ' ', options])
% save and return
out.M = M_;
out.options = options_;
out.oo = oo_;
return
## ------------ first_one.mod ------------
// copypasted from dynare's guide
// ----- Preamble -----
var k l z y c i w r;
varexo e;
parameters beta psi delta alpha rho sigma epsilon;
alpha = alpha_p;
beta = 0.98;
delta = 0.023;
psi = 1.75;
rho = 0.95;
sigma = (0.007/(1-alpha));
epsilon = 10;
// ----- Model -----
model;
(1/c) = beta_(1/c(+1))_(1+r(+1)-delta);
psi_c/(1-l) = w;
c+i = y;
z = rho_z(-1)+e;
y = (k(-1)^alpha)_(exp(z)_l)^(1-alpha);
w = y_((epsilon-1)/epsilon)_(1-alpha)/l;
r = y_((epsilon-1)/epsilon)_alpha/k(-1);
i = k-(1-delta)*k(-1);
end;
// ----- Steady State -----
// almost the exact steady state
initval;
k = 9;
c = 0.7;
l = 0.3;
w = 2.0;
r = 0;
z = 0;
e = 0;
end;
// calculate steady state and set it as the starting point for impulse responce functions
steady;
// Blanchard-Kahn condition check
check;
// ----- Impulse-Responce -----
// shocks
shocks;
var e; stderr 1;
end;
// simulate and plot
// stoch_simul(order = 1) k l z y c i;
4.5https://git.dynare.org/Dynare/dynare/issues/997Fix prior sampling with prior_trunc2019-06-19T15:37:57ZJohannes Pfeifer Fix prior sampling with prior_truncFor the inverse gamma in case of bound violations, sampling instead comes from the inverse gamma I distribution. This yields incorrect results and may result in (almost) infinite loops.
For the uniform distribution, `prior_trunc` is completely ignored.
For the inverse gamma in case of bound violations, sampling instead comes from the inverse gamma I distribution. This yields incorrect results and may result in (almost) infinite loops.
For the uniform distribution, `prior_trunc` is completely ignored.
https://git.dynare.org/Dynare/dynare/issues/992Fix implementation of lik_init==5 part of dsge_likelihood2019-06-19T15:37:57ZJohannes Pfeifer Fix implementation of lik_init==5 part of dsge_likelihood`dsge_likelihood.m` still has the part
```
case options_.lik_init == 5 % Old diffuse Kalman filter only for the non stationary variables
[eigenvect, eigenv] = eig(T);
eigenv = diag(eigenv);
nstable = length(find(abs(abs(eigenv)-1) > 1e-7));
unstable = find(abs(abs(eigenv)-1) < 1e-7);
V = eigenvect(:,unstable);
indx_unstable = find(sum(abs(V),2)>1e-5);
stable = find(sum(abs(V),2)<1e-5);
nunit = length(eigenv) - nstable;
Pstar = options_.Harvey_scale_factor*eye(np);
if kalman_algo ~= 2
kalman_algo = 1;
end
R_tmp = R(stable, :);
T_tmp = T(stable,stable);
if DynareOptions.lyapunov_fp == 1
Pstar_tmp = lyapunov_symm(T_tmp,R_tmp*Q*R_tmp',DynareOptions.lyapunov_fixed_point_tol,DynareOptions.qz_criterium,DynareOptions.lyapunov_complex_threshold, 3, [], DynareOptions.debug);
elseif DynareOptions.lyapunov_db == 1
Pstar_tmp = disclyap_fast(T_tmp,R_tmp*Q*R_tmp',DynareOptions.lyapunov_doubling_tol);
elseif DynareOptions.lyapunov_srs == 1
Pstar_tmp = lyapunov_symm(T_tmp,Q,DynareOptions.lyapunov_fixed_point_tol,DynareOptions.qz_criterium,DynareOptions.lyapunov_complex_threshold, 4, R_tmp, DynareOptions.debug);
else
Pstar_tmp = lyapunov_symm(T_tmp,R_tmp*Q*R_tmp',DynareOptions.qz_criterium,DynareOptions.qz_criterium,DynareOptions.lyapunov_complex_threshold, [], [], DynareOptions.debug);
end
Pstar(stable, stable) = Pstar_tmp;
Pinf = [];
```
that can never be reached. `options_` does not even exist in this function. I propose deleting this part.
`dsge_likelihood.m` still has the part
```
case options_.lik_init == 5 % Old diffuse Kalman filter only for the non stationary variables
[eigenvect, eigenv] = eig(T);
eigenv = diag(eigenv);
nstable = length(find(abs(abs(eigenv)-1) > 1e-7));
unstable = find(abs(abs(eigenv)-1) < 1e-7);
V = eigenvect(:,unstable);
indx_unstable = find(sum(abs(V),2)>1e-5);
stable = find(sum(abs(V),2)<1e-5);
nunit = length(eigenv) - nstable;
Pstar = options_.Harvey_scale_factor*eye(np);
if kalman_algo ~= 2
kalman_algo = 1;
end
R_tmp = R(stable, :);
T_tmp = T(stable,stable);
if DynareOptions.lyapunov_fp == 1
Pstar_tmp = lyapunov_symm(T_tmp,R_tmp*Q*R_tmp',DynareOptions.lyapunov_fixed_point_tol,DynareOptions.qz_criterium,DynareOptions.lyapunov_complex_threshold, 3, [], DynareOptions.debug);
elseif DynareOptions.lyapunov_db == 1
Pstar_tmp = disclyap_fast(T_tmp,R_tmp*Q*R_tmp',DynareOptions.lyapunov_doubling_tol);
elseif DynareOptions.lyapunov_srs == 1
Pstar_tmp = lyapunov_symm(T_tmp,Q,DynareOptions.lyapunov_fixed_point_tol,DynareOptions.qz_criterium,DynareOptions.lyapunov_complex_threshold, 4, R_tmp, DynareOptions.debug);
else
Pstar_tmp = lyapunov_symm(T_tmp,R_tmp*Q*R_tmp',DynareOptions.qz_criterium,DynareOptions.qz_criterium,DynareOptions.lyapunov_complex_threshold, [], [], DynareOptions.debug);
end
Pstar(stable, stable) = Pstar_tmp;
Pinf = [];
```
that can never be reached. `options_` does not even exist in this function. I propose deleting this part.
https://git.dynare.org/Dynare/dynare/issues/988Potentially modify solving Lyapunov equations2019-06-19T15:37:57ZJohannes Pfeifer Potentially modify solving Lyapunov equations@tholden commented on https://github.com/tholden/dynare/commit/69daaa0460b0ddee97292c39d40355201e316622
that
lyapunov_symn is a utility function provided by Dynare that's likely to be useful in a whole number of places when solving and estimating models. If I recall correctly, I had something in my own code where I needed to solve a Lyapunov equation, so I understandably called the dynare function. Since this wasn't in likelihood initialization, I didn't ever notice the lyapunov=doubling option, and the fact that it led to a different function being called.
Indeed, even if you just compare where lyapunov_symn and disclyap_fast are called within Dynare, you'll see that many bits of other code only call the former, e.g. global identification, so I was not the only person led into the trap of calling the inefficient function.
So this issue looks like it was caused by some bad design. It does not make sense for disclyap_fast to be a separate file that must be called as an alternative to lyapunov_symn, particularly since lyapunov_symn already contains code for multiple methods. Either lyapunov_symn should be a shell function with a big "switch" that dispatches to other methods (each with their own function, not just doubling), or it should directly contain those other method's code. The current set-up is terrible for code reusability.
The issue with sparse matrices is another reusability one. The period doubling algorithm is designed for large matrices, and in most reasonable applications, large matrices are sparse. The cost of a few "full" statements is essentially zero when full matrices are passed in to start with. (Incidentally, in large models, significant performance improvements arise from replacing the matrices in dr with sparse ones, so this is perhaps something dynare ought to do anyway. My dynareOBC does this by default.)
In any case, is there really any situation where the algorithm with doubling is beaten by the one without it? The algorithm without doubling seems to be dominated in all regards in my experiments, so it ought to be the default.
I would thus propose to
- integrate `disclyap_fast` into `lyapunov_symm` to have on solver only
- make `lyapunov_symm` able to work with sparse matrices (at least for the baseline option)
- change the baseline option in Dynare to use the doubling algorithm
@rattoma What do you think? You seem to have the most experience with big models. Would you also prefer the doubling algorithm?
@tholden commented on https://github.com/tholden/dynare/commit/69daaa0460b0ddee97292c39d40355201e316622
that
lyapunov_symn is a utility function provided by Dynare that's likely to be useful in a whole number of places when solving and estimating models. If I recall correctly, I had something in my own code where I needed to solve a Lyapunov equation, so I understandably called the dynare function. Since this wasn't in likelihood initialization, I didn't ever notice the lyapunov=doubling option, and the fact that it led to a different function being called.
Indeed, even if you just compare where lyapunov_symn and disclyap_fast are called within Dynare, you'll see that many bits of other code only call the former, e.g. global identification, so I was not the only person led into the trap of calling the inefficient function.
So this issue looks like it was caused by some bad design. It does not make sense for disclyap_fast to be a separate file that must be called as an alternative to lyapunov_symn, particularly since lyapunov_symn already contains code for multiple methods. Either lyapunov_symn should be a shell function with a big "switch" that dispatches to other methods (each with their own function, not just doubling), or it should directly contain those other method's code. The current set-up is terrible for code reusability.
The issue with sparse matrices is another reusability one. The period doubling algorithm is designed for large matrices, and in most reasonable applications, large matrices are sparse. The cost of a few "full" statements is essentially zero when full matrices are passed in to start with. (Incidentally, in large models, significant performance improvements arise from replacing the matrices in dr with sparse ones, so this is perhaps something dynare ought to do anyway. My dynareOBC does this by default.)
In any case, is there really any situation where the algorithm with doubling is beaten by the one without it? The algorithm without doubling seems to be dominated in all regards in my experiments, so it ought to be the default.
I would thus propose to
- integrate `disclyap_fast` into `lyapunov_symm` to have on solver only
- make `lyapunov_symm` able to work with sparse matrices (at least for the baseline option)
- change the baseline option in Dynare to use the doubling algorithm
@rattoma What do you think? You seem to have the most experience with big models. Would you also prefer the doubling algorithm?
https://git.dynare.org/Dynare/dynare/issues/979Make M_.dname more consistent2019-06-19T15:37:57ZMichelJuillardMake M_.dname more consistentM_.dname is used more as an option than as a characteristic of the model file. By default, the directory name of saving output is M_.fname. When the user wants to change the name, this should be setting options_.dname, not M_.dname
M_.dname is used more as an option than as a characteristic of the model file. By default, the directory name of saving output is M_.fname. When the user wants to change the name, this should be setting options_.dname, not M_.dname
https://git.dynare.org/Dynare/dynare/issues/981Expand writing of eps-loaders on consistent basis to identification2019-06-19T15:37:57ZJohannes Pfeifer Expand writing of eps-loaders on consistent basis to identificationLeft after implementing #937
Left after implementing #937
https://git.dynare.org/Dynare/dynare/issues/976Block using parameters as variables in mod-files2019-06-19T15:37:57ZJohannes Pfeifer Block using parameters as variables in mod-filesThe following file defines `pip` as a parameter, but uses `pip(+1)` like a variable. We should block this and issue an error.
```
%%% PROGETTO 11 %%%
var C lambda R r K I MRS h w N mc Y T b W ;
varexo epst ;
parameters beta delta phi eps alpha phir phip phiy tau rho phia phib epsp piw pit sigma pip cy iy b2;
%%% calibrazione parametri %%%
beta=0.99;
delta=0.5;
phi=2;
eps=1;
alpha=2;
phir=0.5;
phip=0.6;
phiy=0.7;
tau=0.35;
rho=0.3;
phia=1;
phib=1.1;
epsp=1.3;
piw=2;
pit=2.3;
sigma=1;
pip=2.1;
cy=1.2;
iy=1.4;
b2=0.7;
%steady state%
model(linear);
-sigma*C=lambda;
lambda=lambda(+1)+R-pip(+1);
lambda(+1)=lambda+(1-beta*(1-delta))*r(+1);
K=(1-delta)*K(-1)+delta*I;
MRS=sigma*C+phi*h;
piw=beta*piw(+1)-(((1-eps)*(1-beta*eps))/eps)*(w-MRS);
K(-1)-N=w-r;
mc=alpha*r+(1-alpha)*w;
Y=alpha*K(-1)+(1-alpha)*h;
pip=beta*pip(+1)+(((1-epsp)*(1-beta*epsp))/epsp)*mc;
(cy)*C+(iy)*I=Y;
R=phir*R(-1)+(1-phir)*(phip*pip+phiy);
T=(1/((((R*b2(-1))/pip)-b2-tau*w*h))*((R*b2(-1))/pip)*(-pip+b2(-1)+R)-(tau*w*h)*(tau+h+w)-b2(-1)*b);
tau=rho*tau(-1)+phia*b(-1)+phib*Y+epst;
piw=w-w(-1)+pip;
end;
resid(1);
steady;
check;
shocks;
var epst=2;
end;
stoch_simul(order=1, irf=20);
```
The following file defines `pip` as a parameter, but uses `pip(+1)` like a variable. We should block this and issue an error.
```
%%% PROGETTO 11 %%%
var C lambda R r K I MRS h w N mc Y T b W ;
varexo epst ;
parameters beta delta phi eps alpha phir phip phiy tau rho phia phib epsp piw pit sigma pip cy iy b2;
%%% calibrazione parametri %%%
beta=0.99;
delta=0.5;
phi=2;
eps=1;
alpha=2;
phir=0.5;
phip=0.6;
phiy=0.7;
tau=0.35;
rho=0.3;
phia=1;
phib=1.1;
epsp=1.3;
piw=2;
pit=2.3;
sigma=1;
pip=2.1;
cy=1.2;
iy=1.4;
b2=0.7;
%steady state%
model(linear);
-sigma*C=lambda;
lambda=lambda(+1)+R-pip(+1);
lambda(+1)=lambda+(1-beta*(1-delta))*r(+1);
K=(1-delta)*K(-1)+delta*I;
MRS=sigma*C+phi*h;
piw=beta*piw(+1)-(((1-eps)*(1-beta*eps))/eps)*(w-MRS);
K(-1)-N=w-r;
mc=alpha*r+(1-alpha)*w;
Y=alpha*K(-1)+(1-alpha)*h;
pip=beta*pip(+1)+(((1-epsp)*(1-beta*epsp))/epsp)*mc;
(cy)*C+(iy)*I=Y;
R=phir*R(-1)+(1-phir)*(phip*pip+phiy);
T=(1/((((R*b2(-1))/pip)-b2-tau*w*h))*((R*b2(-1))/pip)*(-pip+b2(-1)+R)-(tau*w*h)*(tau+h+w)-b2(-1)*b);
tau=rho*tau(-1)+phia*b(-1)+phib*Y+epst;
piw=w-w(-1)+pip;
end;
resid(1);
steady;
check;
shocks;
var epst=2;
end;
stoch_simul(order=1, irf=20);
```
4.5Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/issues/972Change display_problematic_vars_Jacobian.m to use number of auxiliary equati...2019-06-19T15:37:57ZJohannes Pfeifer Change display_problematic_vars_Jacobian.m to use number of auxiliary equations stored by preprocessorSee #729
See #729
https://git.dynare.org/Dynare/dynare/issues/971Improve unit tests for correctness of Kalman filter results2019-06-19T15:37:57ZJohannes Pfeifer Improve unit tests for correctness of Kalman filter resultsFollowing #738, we still need to
- Fix all bugs that result in unit tests crashing
- Improve unit tests to compare likelihood results for consistency
- Update and enable other unit tests for Kalman filter in kalman/likelihood directory
Following #738, we still need to
- Fix all bugs that result in unit tests crashing
- Improve unit tests to compare likelihood results for consistency
- Update and enable other unit tests for Kalman filter in kalman/likelihood directory
https://git.dynare.org/Dynare/dynare/issues/966split output of write_latex_dynamic_model so it can be included in a report2019-06-19T15:37:58ZHoutan Bastanisplit output of write_latex_dynamic_model so it can be included in a reportwrite_latex_dynamic_model can create two files:
1. one containing everything before `\begin{document}`, an `\input` command and an `\end{document}`
2. a second containing the equations that is included in the `\input` command
This second document can also be included in a report if someone wants the model equations in a report.
write_latex_dynamic_model can create two files:
1. one containing everything before `\begin{document}`, an `\input` command and an `\end{document}`
2. a second containing the equations that is included in the `\input` command
This second document can also be included in a report if someone wants the model equations in a report.
4.5Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/issues/965Add posterior distribution of contemporaneous correlations2019-06-19T15:37:58ZJohannes Pfeifer Add posterior distribution of contemporaneous correlationsCurrently, we only save the covariances, but users often want correlations, see e.g. http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=6968.
Currently, we only save the covariances, but users often want correlations, see e.g. http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=6968.
https://git.dynare.org/Dynare/dynare/issues/964Add cholcov function to missing/statistics2019-06-19T15:37:58ZJohannes Pfeifer Add cholcov function to missing/statisticsThe TaRB algorithm makes use of the `cholcov` function of the statistics toolbox. We might want to add the Octave version to the missing folder.
The TaRB algorithm makes use of the `cholcov` function of the statistics toolbox. We might want to add the Octave version to the missing folder.
4.5Johannes Pfeifer Johannes Pfeifer https://git.dynare.org/Dynare/dynare/issues/963Bug in dyn_mex.m2019-06-19T15:37:58ZTom HoldenBug in dyn_mex.mAt present dyn_mex.m uses the undefined variables msvc and cygwin.
It also tries to export the wrong function from the _static.c file.
The fix is in the following commit in my branch: https://github.com/tholden/dynare/commit/0c533744750ed3247fd25c43b1fe82c1fea64bbb
It is also shown here:
Lines 50 to 65 of dyn_mex.m should read as follows:
```
if strcmp( win_compiler, 'msvc' )
% MATLAB/Windows + Microsoft Visual C++
eval(['mex -O LINKFLAGS="$LINKFLAGS /export:Dynamic" ' basename '_dynamic.c ' basename '_dynamic_mex.c'])
eval(['mex -O LINKFLAGS="$LINKFLAGS /export:Static" ' basename '_static.c ' basename '_static_mex.c'])
elseif strcmp( win_compiler, 'cygwin' )
% MATLAB/Windows + Cygwin g++
eval(['mex -O PRELINK_CMDS1="echo EXPORTS > mex.def & echo ' ...
'mexFunction >> mex.def & echo Dynamic >> mex.def" ' ...
basename '_dynamic.c ' basename '_dynamic_mex.c'])
eval(['mex -O PRELINK_CMDS1="echo EXPORTS > mex.def & echo ' ...
'mexFunction >> mex.def & echo Static >> mex.def" ' ...
basename '_static.c ' basename '_static_mex.c'])
else
error(['When using the USE_DLL option, you must give either ' ...
'''cygwin'' or ''msvc'' option to the ''dynare'' command'])
end
```
At present dyn_mex.m uses the undefined variables msvc and cygwin.
It also tries to export the wrong function from the _static.c file.
The fix is in the following commit in my branch: https://github.com/tholden/dynare/commit/0c533744750ed3247fd25c43b1fe82c1fea64bbb
It is also shown here:
Lines 50 to 65 of dyn_mex.m should read as follows:
```
if strcmp( win_compiler, 'msvc' )
% MATLAB/Windows + Microsoft Visual C++
eval(['mex -O LINKFLAGS="$LINKFLAGS /export:Dynamic" ' basename '_dynamic.c ' basename '_dynamic_mex.c'])
eval(['mex -O LINKFLAGS="$LINKFLAGS /export:Static" ' basename '_static.c ' basename '_static_mex.c'])
elseif strcmp( win_compiler, 'cygwin' )
% MATLAB/Windows + Cygwin g++
eval(['mex -O PRELINK_CMDS1="echo EXPORTS > mex.def & echo ' ...
'mexFunction >> mex.def & echo Dynamic >> mex.def" ' ...
basename '_dynamic.c ' basename '_dynamic_mex.c'])
eval(['mex -O PRELINK_CMDS1="echo EXPORTS > mex.def & echo ' ...
'mexFunction >> mex.def & echo Static >> mex.def" ' ...
basename '_static.c ' basename '_static_mex.c'])
else
error(['When using the USE_DLL option, you must give either ' ...
'''cygwin'' or ''msvc'' option to the ''dynare'' command'])
end
```
https://git.dynare.org/Dynare/dynare/issues/959Clean up http://www.dynare.org/events2019-06-19T15:37:58ZJohannes Pfeifer Clean up http://www.dynare.org/eventsThe current ordering is a mess.
The current ordering is a mess.
https://git.dynare.org/Dynare/dynare/issues/953create new class VerbatimStatement2019-06-19T15:37:58ZHoutan Bastanicreate new class VerbatimStatementCurrently, lines in the `verbatim` block are stored as `NativeStatement` objects. This was ok before we decided to replace dates in the preprocessor (e.g. `9q1` with `dates('9q1)`). These dates should be replaced in native statements but not in verbatim statements, hence the new class.
Currently, lines in the `verbatim` block are stored as `NativeStatement` objects. This was ok before we decided to replace dates in the preprocessor (e.g. `9q1` with `dates('9q1)`). These dates should be replaced in native statements but not in verbatim statements, hence the new class.
4.5Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/issues/948Potentially add interface to set parameter bounds for osr.2019-06-19T15:37:58ZJohannes Pfeifer Potentially add interface to set parameter bounds for osr.In principle, there is everything in place to use constrained optimizers with osr. An example on how to use this with a user-defined optimizer wrapper is at http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=6835
However, we do not provide an interface to set such bounds. We should discuss if we should leave it at that (more work for users) or whether we provide functionality to automatically set the bounds (including their correct ordering in the parameter vector).
In principle, there is everything in place to use constrained optimizers with osr. An example on how to use this with a user-defined optimizer wrapper is at http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=6835
However, we do not provide an interface to set such bounds. We should discuss if we should leave it at that (more work for users) or whether we provide functionality to automatically set the bounds (including their correct ordering in the parameter vector).
4.5Johannes Pfeifer Johannes Pfeifer https://git.dynare.org/Dynare/dynare/issues/946Add new preprocessor option minimal_workspace2019-06-19T15:37:58ZJohannes Pfeifer Add new preprocessor option minimal_workspaceMatlab has a limit on the number of variables allowed in the workspace. To prevent problems with this limit, introduce new preprocessor option `minimal_workspace` that when used, suppresses writing the parameters to a variable with their name in the workspace. That is, instead of
```
M_.params( 1 ) = 0.999;
beta = M_.params( 1 );
```
only write
`M_.params( 1 ) = 0.999;`
Also set `options_.minimal_workspace` to 1 (default: 0) so that we can suppress the call to `dyn2vec` in stoch_simul to prevent duplicating simulated variables in the workspace. See the email of Stéphane from 26/05/15
Matlab has a limit on the number of variables allowed in the workspace. To prevent problems with this limit, introduce new preprocessor option `minimal_workspace` that when used, suppresses writing the parameters to a variable with their name in the workspace. That is, instead of
```
M_.params( 1 ) = 0.999;
beta = M_.params( 1 );
```
only write
`M_.params( 1 ) = 0.999;`
Also set `options_.minimal_workspace` to 1 (default: 0) so that we can suppress the call to `dyn2vec` in stoch_simul to prevent duplicating simulated variables in the workspace. See the email of Stéphane from 26/05/15
4.5Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/issues/943Update manual on ordering of variables coming from smoother2019-06-19T15:37:58ZJohannes Pfeifer Update manual on ordering of variables coming from smootherSee http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=6020. Needs to be done after #804
See http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=6020. Needs to be done after #804
4.5