dynare issueshttps://git.dynare.org/Dynare/dynare/issues2019-12-20T16:31:49Zhttps://git.dynare.org/Dynare/dynare/issues/1514Add Importance Ratio as diagnostic for checking accuracy of normal approximat...2019-12-20T16:31:49ZJohannes Pfeifer Add Importance Ratio as diagnostic for checking accuracy of normal approximation to posteriorSee e.g. Slide 32 of http://apps.eui.eu/Personal/Canova/Teachingmaterial/bayes_dsge_eui2012.pdfSee e.g. Slide 32 of http://apps.eui.eu/Personal/Canova/Teachingmaterial/bayes_dsge_eui2012.pdf4.7https://git.dynare.org/Dynare/dynare/issues/1521create class for storing/writing metropolis draws2019-12-20T16:31:36ZHoutan Bastanicreate class for storing/writing metropolis drawsIn the `while` loop of `matlab/posterior_sampler_core.m` we have an example of how draws are stored and written when a certain number of draws have been stored in memory.
Need to create a Matlab class that stores:
- a vector
- a matrix
- a structure (`dr`)
And that writes itself to disk when a certain number of vector/matrix/structures have been written and clears itself so that more draws can be stored.
This class can then be used to standardize the various ways we do this throughout the Matlab codebase.In the `while` loop of `matlab/posterior_sampler_core.m` we have an example of how draws are stored and written when a certain number of draws have been stored in memory.
Need to create a Matlab class that stores:
- a vector
- a matrix
- a structure (`dr`)
And that writes itself to disk when a certain number of vector/matrix/structures have been written and clears itself so that more draws can be stored.
This class can then be used to standardize the various ways we do this throughout the Matlab codebase.4.7https://git.dynare.org/Dynare/dynare/issues/300Implement k-order derivatives of external functions2019-12-16T14:00:55ZSébastien VillemotImplement k-order derivatives of external functionsOtherwise order ≥ 3 fails with a cryptic preprocessor error
Otherwise order ≥ 3 fails with a cryptic preprocessor error
4.7https://git.dynare.org/Dynare/dynare/issues/1684New WITH_TREND() operator for epilogue block2019-12-13T17:29:05ZSébastien VillemotNew WITH_TREND() operator for epilogue blockImplement a new operator (something like `WITH_TREND()` that could be used in the epilogue block, and that would add back the trend on the computed variables. In this way, the symbolic manipulations would be done in the preprocessor, which is much more easier to do than in MATLAB.
Initially discussed in #1648Implement a new operator (something like `WITH_TREND()` that could be used in the epilogue block, and that would add back the trend on the computed variables. In this way, the symbolic manipulations would be done in the preprocessor, which is much more easier to do than in MATLAB.
Initially discussed in #16484.7https://git.dynare.org/Dynare/dynare/issues/1680Adapt evaluate_planner_objective.m to higher order2019-12-12T10:30:23ZJohannes Pfeifer Adapt evaluate_planner_objective.m to higher orderSupersedes https://git.dynare.org/Dynare/dynare/issues/564 and is related to https://git.dynare.org/Dynare/dynare/issues/1678Supersedes https://git.dynare.org/Dynare/dynare/issues/564 and is related to https://git.dynare.org/Dynare/dynare/issues/16784.7https://git.dynare.org/Dynare/dynare/issues/1670Mac Package: see if we can use Homebrew `binutils` package to provide `as` an...2019-11-28T14:46:11ZHoutan BastaniMac Package: see if we can use Homebrew `binutils` package to provide `as` and `ld` and thus not install CLTThe idea is that if we can use Homebrew to provide `as` and `ld` then we can avoid installing Command Line Tools. I am not hopeful because `install_name_tool`, which is used to rename library paths when installing to a non-default directory is installed via Command Line Tools. The thing to check is whether this is used only when installing to non-default directories or whether it is always used. If it is always used, then CLT must not be required (though, it is located in `/Library/Developer/CommandLineTools/usr/bin/install_name_tool`)The idea is that if we can use Homebrew to provide `as` and `ld` then we can avoid installing Command Line Tools. I am not hopeful because `install_name_tool`, which is used to rename library paths when installing to a non-default directory is installed via Command Line Tools. The thing to check is whether this is used only when installing to non-default directories or whether it is always used. If it is always used, then CLT must not be required (though, it is located in `/Library/Developer/CommandLineTools/usr/bin/install_name_tool`)4.7Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/issues/1114create contributions.md describing how to contribute to dynare2019-11-26T16:30:56ZHoutan Bastanicreate contributions.md describing how to contribute to dynareStéphane Adjemianstepan@adjemian.euStéphane Adjemianstepan@adjemian.euhttps://git.dynare.org/Dynare/dynare/issues/1603Investigate whether var_exo_det works correctly with stoch_simul2019-11-26T16:28:38ZJohannes Pfeifer Investigate whether var_exo_det works correctly with stoch_simulSee https://forum.dynare.org/t/varexo-det-to-simulate-random-shocks-during-a-predetermined-period/11637
It seems there is at least one call to `make_ex_` missingSee https://forum.dynare.org/t/varexo-det-to-simulate-random-shocks-during-a-predetermined-period/11637
It seems there is at least one call to `make_ex_` missing4.7https://git.dynare.org/Dynare/dynare/issues/1665Implement bridge sampler for computing marginal data density2019-11-26T16:25:08ZJohannes Pfeifer Implement bridge sampler for computing marginal data density4.7https://git.dynare.org/Dynare/dynare/issues/1004Make initvalf and histvalf compatible with translation to one-lag problem2019-11-26T15:21:02ZJohannes Pfeifer Make initvalf and histvalf compatible with translation to one-lag problemWe currently have both `initvalf` and `histvalf` but with auxiliary variable substitution it is not clear to me how separate the two and how to properly initialize a model. Also, `histvalf` automatically takes care of auxiliary variables while `initvalf` does not.
Related to #617
We currently have both `initvalf` and `histvalf` but with auxiliary variable substitution it is not clear to me how separate the two and how to properly initialize a model. Also, `histvalf` automatically takes care of auxiliary variables while `initvalf` does not.
Related to #617
https://git.dynare.org/Dynare/dynare/issues/1407Keep track of whether smoother results are in logs and adjust smoother2histva...2019-11-26T15:21:02ZJohannes Pfeifer Keep track of whether smoother results are in logs and adjust smoother2histval accordinglySee !1396 See !1396 https://git.dynare.org/Dynare/dynare/issues/829Rewrite local_state_space_iteration_2 routine2019-11-21T08:55:15ZStéphane Adjemianstepan@adjemian.euRewrite local_state_space_iteration_2 routineSeparate the measurement and state equations. See discussions in [particles](https://github.com/DynareTeam/particles/issues) repository.
Separate the measurement and state equations. See discussions in [particles](https://github.com/DynareTeam/particles/issues) repository.
Stéphane Adjemianstepan@adjemian.euStéphane Adjemianstepan@adjemian.euhttps://git.dynare.org/Dynare/dynare/issues/1112homogeneize treatment of leads/lags on exogenous between deterministic and st...2019-11-21T08:52:36ZHoutan Bastanihomogeneize treatment of leads/lags on exogenous between deterministic and stochastic modesAuxiliary variables are treated differently depending on the commands passed in the `.mod` file. As it stands now, if the following conditions hold
```
mod_file_struct.stoch_simul_present
mod_file_struct.estimation_present
mod_file_struct.osr_present
mod_file_struct.ramsey_policy_present
mod_file_struct.discretionary_policy_present
mod_file_struct.calib_smoother_present
```
we substitute endo and exo leads and lags. Otherwise, we only substitute endo leads and lags. This different treatment is undesirable for Julia output, where we will only use the preprocessor to process a model, without having the associated commands. In other words, we want the preprocessor model output to be same, regardless of the commands that are included outside of the `model` block.
As this change requires changes in the matlab code as well, the work will be done on the `aux_func` branch.
Auxiliary variables are treated differently depending on the commands passed in the `.mod` file. As it stands now, if the following conditions hold
```
mod_file_struct.stoch_simul_present
mod_file_struct.estimation_present
mod_file_struct.osr_present
mod_file_struct.ramsey_policy_present
mod_file_struct.discretionary_policy_present
mod_file_struct.calib_smoother_present
```
we substitute endo and exo leads and lags. Otherwise, we only substitute endo leads and lags. This different treatment is undesirable for Julia output, where we will only use the preprocessor to process a model, without having the associated commands. In other words, we want the preprocessor model output to be same, regardless of the commands that are included outside of the `model` block.
As this change requires changes in the matlab code as well, the work will be done on the `aux_func` branch.
Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/issues/1643Implement pruning at order>32019-11-21T08:45:16ZJohannes Pfeifer Implement pruning at order>3The algorithm should follow Andreasen et al. (2018) as already implemented in `simult_.m` for orders 2 and 3. Should be done in the C++ routines of `dynare_simul_` as discussed in https://git.dynare.org/Dynare/dynare/commit/1e92e308b9d0301108d18d7256f47655097f20cb#note_8364The algorithm should follow Andreasen et al. (2018) as already implemented in `simult_.m` for orders 2 and 3. Should be done in the C++ routines of `dynare_simul_` as discussed in https://git.dynare.org/Dynare/dynare/commit/1e92e308b9d0301108d18d7256f47655097f20cb#note_83644.7Sébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/issues/614not balanced growth model not detected by test2019-11-21T08:36:46ZMichelJuillardnot balanced growth model not detected by testHere is an example where an error in trend declaration isn't detected by the balanced growth test. It may come from the fact that labor enhancing productivity (G) is not a variable of the model, just a trend. The error should appear for the equations defining r and w and for the resource constraint.
```
parameters rho delta gamma alpha lambda g;
trend_var(growth_factor=1+g) G;
// the trend of K is wrong:
var(deflator=G) C w;
var L r A K;
// Here is the correct specification:
// var(deflator=G) C w K;
// var L r A;
varexo e;
alpha = 0.33;
delta = 0.1;
rho = 0.03;
lambda = 0.97;
gamma = 0;
g = 0.015;
model;
1/C = 1/(1+rho)*(1/C(+1))*(r(+1)+1-delta);
L^gamma = w/C;
r = alpha*A*K(-1)^(alpha-1)*(G*L)^(1-alpha);
w = (1-alpha)*A*K(-1)^alpha*(G*L)^(-alpha);
K+C = K(-1)*(1-delta)+A*K(-1)^alpha*(G*L)^(1-alpha);
log(A) = lambda*log(A(-1))+e;
end;
steady_state_model;
A = 1;
r = (1+g)*(1+rho)+delta-1;
K_L = (1+g)*(r/(alpha*A))^(1/(alpha-1));
w = (1-alpha)*A*(K_L/(1+g))^alpha;
L = (-((delta+g)/(1+g))*K_L/w+A*(K_L/((1+g)*w^(1/alpha)))^alpha)
^(-1/(1+gamma));
K = K_L*L;
C = (1-delta)*K/(1+g)+(K_L/(1+g))^alpha*L-K;
end;
shocks;
var e; stderr 0.01;
end;
write_latex_dynamic_model;
steady;
check;
stoch_simul(order=1);
```
Here is an example where an error in trend declaration isn't detected by the balanced growth test. It may come from the fact that labor enhancing productivity (G) is not a variable of the model, just a trend. The error should appear for the equations defining r and w and for the resource constraint.
```
parameters rho delta gamma alpha lambda g;
trend_var(growth_factor=1+g) G;
// the trend of K is wrong:
var(deflator=G) C w;
var L r A K;
// Here is the correct specification:
// var(deflator=G) C w K;
// var L r A;
varexo e;
alpha = 0.33;
delta = 0.1;
rho = 0.03;
lambda = 0.97;
gamma = 0;
g = 0.015;
model;
1/C = 1/(1+rho)*(1/C(+1))*(r(+1)+1-delta);
L^gamma = w/C;
r = alpha*A*K(-1)^(alpha-1)*(G*L)^(1-alpha);
w = (1-alpha)*A*K(-1)^alpha*(G*L)^(-alpha);
K+C = K(-1)*(1-delta)+A*K(-1)^alpha*(G*L)^(1-alpha);
log(A) = lambda*log(A(-1))+e;
end;
steady_state_model;
A = 1;
r = (1+g)*(1+rho)+delta-1;
K_L = (1+g)*(r/(alpha*A))^(1/(alpha-1));
w = (1-alpha)*A*(K_L/(1+g))^alpha;
L = (-((delta+g)/(1+g))*K_L/w+A*(K_L/((1+g)*w^(1/alpha)))^alpha)
^(-1/(1+gamma));
K = K_L*L;
C = (1-delta)*K/(1+g)+(K_L/(1+g))^alpha*L-K;
end;
shocks;
var e; stderr 0.01;
end;
write_latex_dynamic_model;
steady;
check;
stoch_simul(order=1);
```
Sébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/issues/6Possible optimization of decision rules at first order2019-11-21T08:36:46ZSébastien VillemotPossible optimization of decision rules at first orderIn dr.pdf, at the end of section 4.1, we have:
g^-_y = Z'_11 T^{-1}_11 S_{11} (Z'_{11})^{-1}
But dr1.m used to contain the following formula:
g^-_y = (T^{-1}_11 X)^{-1} S_{11} X
which is probably more efficient given that X=Z_{11}+Z_{12}g⁺_y (see equation 10), because it saves an inversion
We should make benchmarks between the 2 formulas, because Ondra thinks that for performance reasons, the first method is better, even though this is not obvious.
In dr.pdf, at the end of section 4.1, we have:
g^-_y = Z'_11 T^{-1}_11 S_{11} (Z'_{11})^{-1}
But dr1.m used to contain the following formula:
g^-_y = (T^{-1}_11 X)^{-1} S_{11} X
which is probably more efficient given that X=Z_{11}+Z_{12}g⁺_y (see equation 10), because it saves an inversion
We should make benchmarks between the 2 formulas, because Ondra thinks that for performance reasons, the first method is better, even though this is not obvious.
Sébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/issues/530checking singularity in first order approximation2019-11-21T08:36:46ZMichelJuillardchecking singularity in first order approximationCurrently, we don't check for singularity in first order approximation when solving for static variables (is b10 singular?) or solving for shocks coefficient (is A_ singular?)
1) We should probably add a warning to stoch_simul (and ramsey_policy)
2) Should we care for estimation? Should expand the implicit prior to b10 and A_ non-singular?
3) If b10 is singular, the model has a problem: it is not possible to determine some static variable from the solution of the dynamic part of the model
4) The conditions under which A_ can be singular are mode difficult to determine.
Currently, we don't check for singularity in first order approximation when solving for static variables (is b10 singular?) or solving for shocks coefficient (is A_ singular?)
1) We should probably add a warning to stoch_simul (and ramsey_policy)
2) Should we care for estimation? Should expand the implicit prior to b10 and A_ non-singular?
3) If b10 is singular, the model has a problem: it is not possible to determine some static variable from the solution of the dynamic part of the model
4) The conditions under which A_ can be singular are mode difficult to determine.
https://git.dynare.org/Dynare/dynare/issues/630Improving Ramsey computations2019-11-21T08:36:46ZMichelJuillardImproving Ramsey computations1) adding the possibility to use one of the parameters of the model as the planner_discount factor
2) give independent access to the fonction evaluating the objective function
1) adding the possibility to use one of the parameters of the model as the planner_discount factor
2) give independent access to the fonction evaluating the objective function
MichelJuillardMichelJuillardhttps://git.dynare.org/Dynare/dynare/issues/135Improve display of decision rules with EXPECTATION operator2019-11-21T08:36:45ZSébastien VillemotImprove display of decision rules with EXPECTATION operatorCurrently, if the user inputs EXPECTATION(-1)(some_expr) in her model, then a new aux variable is created, and this var is a state var, which appears in the decision rules as EXPECTATION(-1)(...) (with the dots instead of the expression). This is not very informative. Displaying the full expression would require to add a new writeOutput method in the preprocessor.
And for something like EXPECTATION(-2)(some_expr), it is even worse, because there are 2 aux vars: one for the operator, and the second one which appears when removing lags of 2. It is the latter which appears in stoch_simul. Fixing this requires to fix the orig_endo field of M_.aux_vars in that case.
Currently, if the user inputs EXPECTATION(-1)(some_expr) in her model, then a new aux variable is created, and this var is a state var, which appears in the decision rules as EXPECTATION(-1)(...) (with the dots instead of the expression). This is not very informative. Displaying the full expression would require to add a new writeOutput method in the preprocessor.
And for something like EXPECTATION(-2)(some_expr), it is even worse, because there are 2 aux vars: one for the operator, and the second one which appears when removing lags of 2. It is the latter which appears in stoch_simul. Fixing this requires to fix the orig_endo field of M_.aux_vars in that case.
https://git.dynare.org/Dynare/dynare/issues/1204Crash in unstable mex when called from parallel workers2019-11-21T08:36:45ZTom HoldenCrash in unstable mex when called from parallel workersI'm afraid I don't have time to produce a minimal example of this bug now, but I'll leave the replication steps here in case anyone else does.
1) Download my version of Dynare, with sub-modules from https://github.com/tholden/dynare
2) Replace the files in the mex subfolder with those from the latest unstable.
3) Browse to the dynare\examples\nonlinear-estimation directory within MATLAB, and then execute `dynare NKNonCentralEstimate.mod`
4) Note that Dynare correctly calculates the initial likelihood, but then when it starts calculating the first numerical derivative of the likelihood, in parallel, each of the parallel workers crash in turn.
5) Reset the repository so you have my compiled MEX. Rerun the same test and observe that the parallel workers do not crash.
I would strongly expect that in fact you don't need to use my version of Dynare, or to use my code for estimating an approximation around the mean, and in the latest unstable this ought to be present whenever you evaluate the likelihood in parallel.
I'm afraid I don't have time to produce a minimal example of this bug now, but I'll leave the replication steps here in case anyone else does.
1) Download my version of Dynare, with sub-modules from https://github.com/tholden/dynare
2) Replace the files in the mex subfolder with those from the latest unstable.
3) Browse to the dynare\examples\nonlinear-estimation directory within MATLAB, and then execute `dynare NKNonCentralEstimate.mod`
4) Note that Dynare correctly calculates the initial likelihood, but then when it starts calculating the first numerical derivative of the likelihood, in parallel, each of the parallel workers crash in turn.
5) Reset the repository so you have my compiled MEX. Rerun the same test and observe that the parallel workers do not crash.
I would strongly expect that in fact you don't need to use my version of Dynare, or to use my code for estimating an approximation around the mean, and in the latest unstable this ought to be present whenever you evaluate the likelihood in parallel.
Stéphane Adjemianstepan@adjemian.euStéphane Adjemianstepan@adjemian.eu