dynare issueshttps://git.dynare.org/Dynare/dynare/issues2018-09-11T15:00:44Zhttps://git.dynare.org/Dynare/dynare/issues/773Fix preprocessor info on auxiliary variables2018-09-11T15:00:44ZJohannes Pfeifer Fix preprocessor info on auxiliary variablesSee #770
See #770
5.0Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/issues/762svar identification2018-09-11T15:00:44ZHoutan Bastanisvar identificationimplement partial/global identification for svar, based on Tao's paper
implement partial/global identification for svar, based on Tao's paper
5.0MichelJuillardMichelJuillardhttps://git.dynare.org/Dynare/dynare/issues/642Support Dirichlet prior distribution2018-09-11T15:00:44ZHoutan BastaniSupport Dirichlet prior distributionAdding dirichlet to the prior shape option for #568. Needs to be supported in estimation as well.
Adding dirichlet to the prior shape option for #568. Needs to be supported in estimation as well.
5.0https://git.dynare.org/Dynare/dynare/issues/630Improving Ramsey computations2018-11-08T10:34:14ZMichelJuillardImproving 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
5.0MichelJuillardMichelJuillardhttps://git.dynare.org/Dynare/dynare/issues/614not balanced growth model not detected by test2018-11-08T09:52:18ZMichelJuillardnot 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);
```
5.0Sébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/issues/569Integrate OccBin2019-09-12T14:48:25ZHoutan BastaniIntegrate OccBinhttps://github.com/lucashare/occbin
https://www2.bc.edu/matteo-iacoviello/research_files/TOOLKIT_PAPER.pdf
https://github.com/lucashare/occbin
https://www2.bc.edu/matteo-iacoviello/research_files/TOOLKIT_PAPER.pdf
5.0MichelJuillardMichelJuillardhttps://git.dynare.org/Dynare/dynare/issues/568Integrate DMM2018-11-08T11:49:07ZHoutan BastaniIntegrate DMMhttp://ipsc.jrc.ec.europa.eu/?id=790
http://ipsc.jrc.ec.europa.eu/fileadmin/repository/sfa/finepro/software/DMMmanual.pdf
http://ipsc.jrc.ec.europa.eu/?id=790
http://ipsc.jrc.ec.europa.eu/fileadmin/repository/sfa/finepro/software/DMMmanual.pdf
5.0MichelJuillardMichelJuillardhttps://git.dynare.org/Dynare/dynare/issues/564ramsey policy at order 22019-08-14T12:17:39ZMichelJuillardramsey policy at order 2The code for computing a 2nd order approximation of Ramsey policy is already in place. I just need to complete the evaluation of objective function (at 3rd order).
The code for computing a 2nd order approximation of Ramsey policy is already in place. I just need to complete the evaluation of objective function (at 3rd order).
5.0MichelJuillardMichelJuillardhttps://git.dynare.org/Dynare/dynare/issues/530checking singularity in first order approximation2018-11-08T11:49:07ZMichelJuillardchecking 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.
5.0https://git.dynare.org/Dynare/dynare/issues/416Document how to do learning with Dynare2019-06-19T15:37:41ZJohannes Pfeifer Document how to do learning with DynareSee http://www.dynare.org/pipermail/dev/2013-May/003256.html
See http://www.dynare.org/pipermail/dev/2013-May/003256.html
5.0Stéphane Adjemianstepan@dynare.orgStéphane Adjemianstepan@dynare.orghttps://git.dynare.org/Dynare/dynare/issues/386k_order_perturbation MEX: error messages are uninformative2019-08-14T12:25:01ZMichelJuillardk_order_perturbation MEX: error messages are uninformativeThe k_order_perturbation MEX doesn't return error information similar to the ones that we have in the MATLAB code for 1st and 2nd order solution. This will create a problem if we want to use the MEX for nonlinear estimation.
The k_order_perturbation MEX doesn't return error information similar to the ones that we have in the MATLAB code for 1st and 2nd order solution. This will create a problem if we want to use the MEX for nonlinear estimation.
5.0Sébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/issues/349Use preprocessor for loglinearization2019-06-19T15:37:41ZJohannes Pfeifer Use preprocessor for loglinearizationAn often heard request is a way to loglinearize a model instead of a linearization. Currently, the way to go is to put all variables in exp(). This is mechanic and error-prone work.
If it is easily doable, I would like to propose to use the preprocessor to make this substitution, similar to the predetermined_variables-command substituting the lag of the current period.
We could then add a command like
`model(loglinearize)`
to tell the preprocessor to loglinearize.
At the same time, we need a command like `non_logarithmic_variables` similar to the `predetermined_variables` command to exclude already logarithmic variables (like e.g. technology) or variables with a negative steady state. I think this is a better option than specifying explicitly which variables to substitute.
If possible, a design issue we would need to discuss is the behavior in steady state computation. I would suggest that the `model(loglinearize)` automatically triggers taking the log of the corresponding initvals so that users can enter the model in nonlinear standard form and Dynare takes care of the rest.
An often heard request is a way to loglinearize a model instead of a linearization. Currently, the way to go is to put all variables in exp(). This is mechanic and error-prone work.
If it is easily doable, I would like to propose to use the preprocessor to make this substitution, similar to the predetermined_variables-command substituting the lag of the current period.
We could then add a command like
`model(loglinearize)`
to tell the preprocessor to loglinearize.
At the same time, we need a command like `non_logarithmic_variables` similar to the `predetermined_variables` command to exclude already logarithmic variables (like e.g. technology) or variables with a negative steady state. I think this is a better option than specifying explicitly which variables to substitute.
If possible, a design issue we would need to discuss is the behavior in steady state computation. I would suggest that the `model(loglinearize)` automatically triggers taking the log of the corresponding initvals so that users can enter the model in nonlinear standard form and Dynare takes care of the rest.
5.0https://git.dynare.org/Dynare/dynare/issues/339Clarify difference between Bayesian HPDI and classical confidence bands in ma...2019-06-19T15:37:41ZJohannes Pfeifer Clarify difference between Bayesian HPDI and classical confidence bands in manualMention in manual that ML gives CIs and not HPDIs. More fundamentally, I am not sure whether it is a good idea to store CIs after ML in fields named HPDinf and HPDsup.
Mention in manual that ML gives CIs and not HPDIs. More fundamentally, I am not sure whether it is a good idea to store CIs after ML in fields named HPDinf and HPDsup.
5.0https://git.dynare.org/Dynare/dynare/issues/294rework option handling2019-06-19T15:37:42ZSébastien Villemotrework option handlingIt's desirable at times to know whether or not a user has set an option in the .mod file.
To do this, we can hack the preprocessor to maintain a separate cellarray, that it would assign to every time it encounters an option. Something to the effect of:
'option' , assigned , default_val
<<string>>, <<0 or 1>>, <<general>>
This can be done in the preprocessor without changing the backend matlab code. It would thereby provide the possibility, when needed, to check whether or not an option was assigned by the user, allowing us to know whether or not we can change the value.
It's desirable at times to know whether or not a user has set an option in the .mod file.
To do this, we can hack the preprocessor to maintain a separate cellarray, that it would assign to every time it encounters an option. Something to the effect of:
'option' , assigned , default_val
<<string>>, <<0 or 1>>, <<general>>
This can be done in the preprocessor without changing the backend matlab code. It would thereby provide the possibility, when needed, to check whether or not an option was assigned by the user, allowing us to know whether or not we can change the value.
5.0Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/issues/237Document sbvar command2019-06-19T15:37:42ZSébastien VillemotDocument sbvar command5.0MichelJuillardMichelJuillardhttps://git.dynare.org/Dynare/dynare/issues/147Accuracy checks2019-06-19T15:37:43ZSébastien VillemotAccuracy checks5.0https://git.dynare.org/Dynare/dynare/issues/135Improve display of decision rules with EXPECTATION operator2019-06-19T15:37:43ZSé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.
5.0https://git.dynare.org/Dynare/dynare/issues/133datafile option in simul2019-06-19T15:37:43ZSébastien Villemotdatafile option in simulthis option is very similar to initval_file but it requires two different files for endogenous and exogenous variables.
The entry in the manual doesn't describe the required files.
It may be interesting to use it for loading only trajectories for the exogenous variables.
this option is very similar to initval_file but it requires two different files for endogenous and exogenous variables.
The entry in the manual doesn't describe the required files.
It may be interesting to use it for loading only trajectories for the exogenous variables.
5.0https://git.dynare.org/Dynare/dynare/issues/116IRF: give the possibility to choose the starting point (at least at order 2 a...2019-06-19T15:37:43ZSébastien VillemotIRF: give the possibility to choose the starting point (at least at order 2 and above)In particular, give the possibility to start from the stochastic steady state
In particular, give the possibility to start from the stochastic steady state
5.0https://git.dynare.org/Dynare/dynare/issues/115IRF: add the possibility to change the size of the shocks in the computations2019-06-19T15:37:43ZSébastien VillemotIRF: add the possibility to change the size of the shocks in the computationsAt order 1, it is equivalent to changing the standard deviation of the shocks and adding the corresponding inverse transformation in the equations.
But at orders 2 and above, the equivalence does not hold.
At order 1, it is equivalent to changing the standard deviation of the shocks and adding the corresponding inverse transformation in the equations.
But at orders 2 and above, the equivalence does not hold.
5.0