dynare issueshttps://git.dynare.org/Dynare/dynare/-/issues2019-11-27T16:33:42Zhttps://git.dynare.org/Dynare/dynare/-/issues/825Fix using steady state operator on exogenous variables2019-11-27T16:33:42ZJohannes Pfeifer Fix using steady state operator on exogenous variablesThe mod-file
```
var c, h, pi, w, R, r_e, y, gdp, gdp_hat, k, g, w_tilde, w_eq, w_min;
varexo d, z, eta;
parameters beta, sigma, gamma, theta, ni, tau_w, phi_p, phi_y, rho, alpha;
beta = 0.997;
sigma = 1;
gamma = 458.4;
theta = 6.1;
tau_w = 0.2;
ni = 0.28;
phi_p = 1.5;
phi_y = 0.125;
rho = 0.3;
alpha = 0.064;
model;
w_tilde=rho/(1+pi)*w(-1)+(1-rho)*w_eq;
w_eq =(1-alpha)*steady_state(z)*steady_state(h)^(-alpha);
w_min =w(-1)/(1+pi);
//mrs=c^sigma*h^ni/(1-tau_w);
gdp_hat =log(gdp)-log(steady_state(gdp));
r_e=1/(beta*d(+1))-1;
//FOC labor
c^sigma*h^ni=max(w_tilde,w_min)*(1-tau_w);
//Euler equation 1
1=beta*d(+1)*(1+R)/(1+pi(+1))*(c/c(+1))^sigma;
//Euler equation 2
0=(1/(1-alpha))*max(w_tilde,w_min)/z*h^alpha-1-gamma/theta*pi*(1+pi)+beta*d(+1)*(c/c(+1))^sigma * y(+1)/y*gamma/theta*pi(+1)*(1+pi(+1));
// Taylor rule with ZLB
R=max(0,r_e+phi_p*pi+phi_y*gdp_hat);
//output
y=z*h^(1-alpha);
//aggregate resource constraint
c=(1-k-eta)*y;
// resource cost of price adjustment
k=(gamma/2)*(pi^2);
//government purchases
g=eta*y;
// GDP
gdp=(1-k)*y;
//utility
//u=(c^(1-sigma))/(1-sigma)-(h^(1+ni))/(1+ni);
end;
initval;
z=1;
d=1;
pi=0;
k=(gamma/2)*(pi^2);
r_e=1/(beta*d)-1;
h=1;
y=z*h^(1-alpha);
g=eta*y;
c=(1-k-eta)*y;
//w=z;
//w=(1-alpha)/(h^alpha);
gdp=(1-k)*y;
R=r_e;
eta=0.2;
end;
steady;
check;
```
uses `steady_state(z)` where `z` is an exogenous variable. In the `_dynamic` file, the preprocessor translates this to `oo_.exo_steady_state(2)` which does not exist in the `_dynamic` file, leading to a crash. We should either disallow using the steady state operator on exogenous variables or simply enforce that the steady state of exogenous variables is 0. I would prefer the first one as the second would only be viable for stochastic simulations.
The mod-file
```
var c, h, pi, w, R, r_e, y, gdp, gdp_hat, k, g, w_tilde, w_eq, w_min;
varexo d, z, eta;
parameters beta, sigma, gamma, theta, ni, tau_w, phi_p, phi_y, rho, alpha;
beta = 0.997;
sigma = 1;
gamma = 458.4;
theta = 6.1;
tau_w = 0.2;
ni = 0.28;
phi_p = 1.5;
phi_y = 0.125;
rho = 0.3;
alpha = 0.064;
model;
w_tilde=rho/(1+pi)*w(-1)+(1-rho)*w_eq;
w_eq =(1-alpha)*steady_state(z)*steady_state(h)^(-alpha);
w_min =w(-1)/(1+pi);
//mrs=c^sigma*h^ni/(1-tau_w);
gdp_hat =log(gdp)-log(steady_state(gdp));
r_e=1/(beta*d(+1))-1;
//FOC labor
c^sigma*h^ni=max(w_tilde,w_min)*(1-tau_w);
//Euler equation 1
1=beta*d(+1)*(1+R)/(1+pi(+1))*(c/c(+1))^sigma;
//Euler equation 2
0=(1/(1-alpha))*max(w_tilde,w_min)/z*h^alpha-1-gamma/theta*pi*(1+pi)+beta*d(+1)*(c/c(+1))^sigma * y(+1)/y*gamma/theta*pi(+1)*(1+pi(+1));
// Taylor rule with ZLB
R=max(0,r_e+phi_p*pi+phi_y*gdp_hat);
//output
y=z*h^(1-alpha);
//aggregate resource constraint
c=(1-k-eta)*y;
// resource cost of price adjustment
k=(gamma/2)*(pi^2);
//government purchases
g=eta*y;
// GDP
gdp=(1-k)*y;
//utility
//u=(c^(1-sigma))/(1-sigma)-(h^(1+ni))/(1+ni);
end;
initval;
z=1;
d=1;
pi=0;
k=(gamma/2)*(pi^2);
r_e=1/(beta*d)-1;
h=1;
y=z*h^(1-alpha);
g=eta*y;
c=(1-k-eta)*y;
//w=z;
//w=(1-alpha)/(h^alpha);
gdp=(1-k)*y;
R=r_e;
eta=0.2;
end;
steady;
check;
```
uses `steady_state(z)` where `z` is an exogenous variable. In the `_dynamic` file, the preprocessor translates this to `oo_.exo_steady_state(2)` which does not exist in the `_dynamic` file, leading to a crash. We should either disallow using the steady state operator on exogenous variables or simply enforce that the steady state of exogenous variables is 0. I would prefer the first one as the second would only be viable for stochastic simulations.
4.6MichelJuillardMichelJuillardhttps://git.dynare.org/Dynare/dynare/-/issues/915Integrate convert_dyn_45_to_44 into convert_oo_.m2019-11-27T13:11:55ZJohannes Pfeifer Integrate convert_dyn_45_to_44 into convert_oo_.mSee the discussion in https://github.com/DynareTeam/dynare/commit/a93e0157e4ea0d3a2ee4d5b10842066a0a39c2e9#commitcomment-10984144
See the discussion in https://github.com/DynareTeam/dynare/commit/a93e0157e4ea0d3a2ee4d5b10842066a0a39c2e9#commitcomment-10984144
4.6Sébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/674Improve error message in Dynare++ for BK-Violation2019-11-27T13:11:54ZJohannes Pfeifer Improve error message in Dynare++ for BK-ViolationSee http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=5790
See http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=5790
Sébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/1662Add support for linear models in perfect_foresight_problem MEX2019-11-27T13:11:54ZSébastien VillemotAdd support for linear models in perfect_foresight_problem MEXIn that case, the Jacobian needs not be recomputed for each period.In that case, the Jacobian needs not be recomputed for each period.Sébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/1639Add the possibility to use Matlab's namespace in model block2019-11-27T13:11:53ZStéphane Adjemianstepan@adjemian.euAdd the possibility to use Matlab's namespace in model block... or in `steady_state_model` block, where it should be possible to write something like:
```
z = example.z_steadystate();
```
provided that the file `+example/z_steadystate` exists.... or in `steady_state_model` block, where it should be possible to write something like:
```
z = example.z_steadystate();
```
provided that the file `+example/z_steadystate` exists.4.6Houtan 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/1655Move created LaTeX-files to subfolder2019-11-21T14:15:56ZJohannes Pfeifer Move created LaTeX-files to subfolderSee https://git.dynare.org/Dynare/preprocessor/commit/0988a1f755be01b00aab7a458c89d9b63800875d#note_8528See https://git.dynare.org/Dynare/preprocessor/commit/0988a1f755be01b00aab7a458c89d9b63800875d#note_85284.6Johannes Pfeifer Johannes Pfeifer https://git.dynare.org/Dynare/dynare/-/issues/1659Filter out non-positive definite Hessians before Laplace approximation2019-11-21T14:06:17ZJohannes Pfeifer Filter out non-positive definite Hessians before Laplace approximationWe do not check whether the normal approximation underlying the Laplace approximation to the marginal data density makes any sense given the Hessian at hand. That results in wrong output, because the log determinant will be complex and Matlab only prints the real-valued parts.
See https://forum.dynare.org/t/hessian-matrix-at-the-mode-is-not-positive-definite-but-the-marginal-density-is-displayed-anyway/14510/3
Proposed solution: skip the computation of the Hessian is not positive semi-definite and return NaN.We do not check whether the normal approximation underlying the Laplace approximation to the marginal data density makes any sense given the Hessian at hand. That results in wrong output, because the log determinant will be complex and Matlab only prints the real-valued parts.
See https://forum.dynare.org/t/hessian-matrix-at-the-mode-is-not-positive-definite-but-the-marginal-density-is-displayed-anyway/14510/3
Proposed solution: skip the computation of the Hessian is not positive semi-definite and return NaN.4.6Johannes Pfeifer Johannes Pfeifer 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/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/563Potentially change treatment of #-expressions in LaTeX - Code2019-11-21T08:36:46ZJohannes Pfeifer Potentially change treatment of #-expressions in LaTeX - CodeI have a mod-file where I use `write_latex_dynamic_model;`
The file contains an expression
`#delta_2=delta_2divdelta_1*delta_1;`
We should try to add a way to define a LaTeX name for this expression. Moreover, I noticed that sometimes, the LaTeX-Code adds a time t-index to this expression although expressions cannot be lagged or leaded. This should also be removed if possible.
I have a mod-file where I use `write_latex_dynamic_model;`
The file contains an expression
`#delta_2=delta_2divdelta_1*delta_1;`
We should try to add a way to define a LaTeX name for this expression. Moreover, I noticed that sometimes, the LaTeX-Code adds a time t-index to this expression although expressions cannot be lagged or leaded. This should also be removed if possible.
Houtan BastaniHoutan Bastanihttps://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/780Deal with options_.nobs and options_.first_obs in master2019-11-21T08:36:46ZJohannes Pfeifer Deal with options_.nobs and options_.first_obs in masterWith the new data interface, these fields are not always set, leading to crashes in different places. For example, recursive forecasting still relies on those fields. See also afb5be206741457a9b6383fa004bb3f208ed5d94
We need to decide on how to treat them. Are these field properties of the dataset to be moved into `dataset_`? Or are they to be used as options in other commands?
With the new data interface, these fields are not always set, leading to crashes in different places. For example, recursive forecasting still relies on those fields. See also afb5be206741457a9b6383fa004bb3f208ed5d94
We need to decide on how to treat them. Are these field properties of the dataset to be moved into `dataset_`? Or are they to be used as options in other commands?
Stéphane Adjemianstepan@adjemian.euStéphane Adjemianstepan@adjemian.euhttps://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
MichelJuillardMichelJuillard