dynare issueshttps://git.dynare.org/Dynare/dynare/issues2018-09-10T12:35:46Zhttps://git.dynare.org/Dynare/dynare/issues/1605Better document behavior of steady_state operator2018-09-10T12:35:46ZJohannes Pfeifer Better document behavior of steady_state operatorSee https://forum.dynare.org/t/steady-state-command-in-perfect-foresight-simulations/11632/3See https://forum.dynare.org/t/steady-state-command-in-perfect-foresight-simulations/11632/3https://git.dynare.org/Dynare/dynare/issues/1597Accept UTF-8 in .mod file2018-09-10T12:35:46ZHoutan BastaniAccept UTF-8 in .mod fileHoutan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/issues/1565initial condition decomposition2018-09-10T12:35:46ZMarco Rattoinitial condition decompositionit would be useful to add interface for the following options:
```
nodisplay
graph_format
fig_name
```
Moreover, the preprocessor should give a lhs arg oo_ when translating the command, i.e.:
`oo_ = initial_condition_decomposition(M_,oo_,options_,var_list_,bayestopt_,estim_params_);`
so not really new options, but just allow those in the pre-processor. many thanks!it would be useful to add interface for the following options:
```
nodisplay
graph_format
fig_name
```
Moreover, the preprocessor should give a lhs arg oo_ when translating the command, i.e.:
`oo_ = initial_condition_decomposition(M_,oo_,options_,var_list_,bayestopt_,estim_params_);`
so not really new options, but just allow those in the pre-processor. many thanks!4.6Johannes Pfeifer Johannes Pfeifer https://git.dynare.org/Dynare/dynare/issues/1170Non-bayesian estimation should use quasi-Maximum likelihood standard errors2018-09-11T15:00:44ZTom HoldenNon-bayesian estimation should use quasi-Maximum likelihood standard errorsAt present, with non-Bayesian estimation, Dynare computes standard errors using the Hessian of the likelihood. This is only valid if it is assumed that the shocks in the "true" model are normally distributed. And, in that case, it is an inefficient way of computing the standard errors, as it will be equal to the Fisher information matrix, which only requires the calculation of the derivative of the score vector.
It would make more sense to default to computing quasi-Maximum likelihood "sandwich" covariances, with the option to use the Fisher information matrix if the user wants quicker results.
At present, with non-Bayesian estimation, Dynare computes standard errors using the Hessian of the likelihood. This is only valid if it is assumed that the shocks in the "true" model are normally distributed. And, in that case, it is an inefficient way of computing the standard errors, as it will be equal to the Fisher information matrix, which only requires the calculation of the derivative of the score vector.
It would make more sense to default to computing quasi-Maximum likelihood "sandwich" covariances, with the option to use the Fisher information matrix if the user wants quicker results.
5.0Marco RattoMarco Rattohttps://git.dynare.org/Dynare/dynare/issues/835Behavior of STEADY_STATE() in perfect foresight models with anticipated perma...2018-09-11T15:00:44ZStéphane Adjemianstepan@dynare.orgBehavior of STEADY_STATE() in perfect foresight models with anticipated permanent shocks.In the current state, `STEADY_STATE(X)` return the terminal steady state of variable X in the dynamic model (`oo_.steady_state(i)`). Is this correct in the periods preceding the permanent shock? What if we have more than one permanent shock (at different periods)? @FerhatMihoubi raised this issue yesterday in a discussion. There is a mechanism in the bytecode routines to handle this case by considering different steady state between each (expected) permanent shock (actually this part of the code is not working). For me it is far from obvious that the steady state should change (unless the permanent shocks are unexpected, but there is noisy interface for this kind of scenario in Dynare).
In the current state, `STEADY_STATE(X)` return the terminal steady state of variable X in the dynamic model (`oo_.steady_state(i)`). Is this correct in the periods preceding the permanent shock? What if we have more than one permanent shock (at different periods)? @FerhatMihoubi raised this issue yesterday in a discussion. There is a mechanism in the bytecode routines to handle this case by considering different steady state between each (expected) permanent shock (actually this part of the code is not working). For me it is far from obvious that the steady state should change (unless the permanent shocks are unexpected, but there is noisy interface for this kind of scenario in Dynare).
5.0https://git.dynare.org/Dynare/dynare/issues/1162Handling of trends2018-09-11T15:00:44ZMichelJuillardHandling of trendsCurrently trends are taken into account only if users indicate them for observed variables. However, in random walk with drift, a deterministic trend appears endogenously for variables that are not necessarily observed.
Let consider the following model where only Y is observed:
```
A_t = A_{t-1} + g + e_t
Y_t = A_t + eta_t
```
Both A_t and Y_t contain a deterministic linear trend with a slope of g. The current practice of only specifying the trend of Y is not satisfactory anymore.
When using the smoother, we need to recognize these trends and include them in SmoothedVariables and friends
Currently trends are taken into account only if users indicate them for observed variables. However, in random walk with drift, a deterministic trend appears endogenously for variables that are not necessarily observed.
Let consider the following model where only Y is observed:
```
A_t = A_{t-1} + g + e_t
Y_t = A_t + eta_t
```
Both A_t and Y_t contain a deterministic linear trend with a slope of g. The current practice of only specifying the trend of Y is not satisfactory anymore.
When using the smoother, we need to recognize these trends and include them in SmoothedVariables and friends
5.0https://git.dynare.org/Dynare/dynare/issues/1112treatment of auxiliary variables2018-09-11T15:00:44ZHoutan Bastanitreatment of auxiliary variablesAuxiliary 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.
5.0Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/issues/831Improve homotopy2018-09-11T15:00:44ZStéphane Adjemianstepan@dynare.orgImprove homotopy- [X] Display more informations about the progress of the algorithm.
- [X] Do not display warnings.
- [X] Set verbosity to 0 when entering in the homotopy.
- [X] Fix homotopy with `block` and `bytecode` options.
- [ ] Fix display of informations with `bytecode options`.
- [X] Display more informations about the progress of the algorithm.
- [X] Do not display warnings.
- [X] Set verbosity to 0 when entering in the homotopy.
- [X] Fix homotopy with `block` and `bytecode` options.
- [ ] Fix display of informations with `bytecode options`.
5.0Stéphane Adjemianstepan@dynare.orgStéphane Adjemianstepan@dynare.orghttps://git.dynare.org/Dynare/dynare/issues/1093Discuss changing options_.hp_ngrid2018-09-11T15:00:44ZJohannes Pfeifer Discuss changing options_.hp_ngridThe option `options_.hp_ngrid` is now badly named after introducing a `bandpass_filter` option. It actually governs the number of points used in the inverse Fourier transform for any filter (see #1011).
I would suggest creating a new option `ifft_points` in the options structure and the preprocessor. For backward compatibility we should keep `hp_ngrid` in the preprocesor, but have it now map into `options_.ifft_points`
The option `options_.hp_ngrid` is now badly named after introducing a `bandpass_filter` option. It actually governs the number of points used in the inverse Fourier transform for any filter (see #1011).
I would suggest creating a new option `ifft_points` in the options structure and the preprocessor. For backward compatibility we should keep `hp_ngrid` in the preprocesor, but have it now map into `options_.ifft_points`
https://git.dynare.org/Dynare/dynare/issues/1534Add documentation for SMM/GMM/IRF options2018-09-11T15:00:44ZJohannes Pfeifer Add documentation for SMM/GMM/IRF optionsRelevant commits are https://github.com/DynareTeam/dynare/commit/254a73a4065a4b476296391dd22672637f82fc72 and https://github.com/DynareTeam/dynare/commit/d52f13114d10fbe5fd4d263d5d0b9d7cfda787f6Relevant commits are https://github.com/DynareTeam/dynare/commit/254a73a4065a4b476296391dd22672637f82fc72 and https://github.com/DynareTeam/dynare/commit/d52f13114d10fbe5fd4d263d5d0b9d7cfda787f64.6Johannes Pfeifer Johannes Pfeifer https://git.dynare.org/Dynare/dynare/issues/829Rewrite local_state_space_iteration_2 routine2018-09-11T15:00:44ZStéphane Adjemianstepan@dynare.orgRewrite 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.
5.0Stéphane Adjemianstepan@dynare.orgStéphane Adjemianstepan@dynare.orghttps://git.dynare.org/Dynare/dynare/issues/1308Factorize print_info and interpret_resol_info2018-09-11T15:00:44ZStéphane Adjemianstepan@dynare.orgFactorize print_info and interpret_resol_infoSee discussion [here](https://github.com/DynareTeam/dynare/commit/83bc67f0c03bcd79cbbe4c903d7e5f5d4bc11e88#commitcomment-19332156).
See discussion [here](https://github.com/DynareTeam/dynare/commit/83bc67f0c03bcd79cbbe4c903d7e5f5d4bc11e88#commitcomment-19332156).
4.6Stéphane Adjemianstepan@dynare.orgStéphane Adjemianstepan@dynare.orghttps://git.dynare.org/Dynare/dynare/issues/1060Add capabilities for pseudo out of sample forecasting2018-09-11T15:00:44ZJohannes Pfeifer Add capabilities for pseudo out of sample forecastingAllow estimating model parameters on one part of the data and then, holding the estimated parameters fixed, forecast observations after the end of the sample used for estimation. See discussion on mailing list from September 14, 2015
Allow estimating model parameters on one part of the data and then, holding the estimated parameters fixed, forecast observations after the end of the sample used for estimation. See discussion on mailing list from September 14, 2015
5.0https://git.dynare.org/Dynare/dynare/issues/1056Document the data command2018-09-11T15:00:44ZStéphane Adjemianstepan@dynare.orgDocument the data commandStéphane Adjemianstepan@dynare.orgStéphane Adjemianstepan@dynare.orghttps://git.dynare.org/Dynare/dynare/issues/1282MS-SBVAR: Potentially allow for linear restrictions across A0 and Aplus2018-09-11T15:00:44ZJohannes Pfeifer MS-SBVAR: Potentially allow for linear restrictions across A0 and AplusAfter a user inquiry at http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=9594, @dwaggoner replied with the following. The question is now whether we want to implement this?
The underlying C code can handle linear restrictions across `A0` and `Aplus` as long as they are not cross-equation. Also the restrictions must be linear, not affine, i.e. no non-zero constant. It seems like this is what the person is asking for. Also, this cannot be used with the Sims-Zha specification as that requires `Aplus` to be unrestricted.
Each column (equation) of `A0` and Aplus can be restricted to be of the form
```
a_j = U[j]*b_j
aplus_j = V[j]*g_j + W[j]*a_j
```
Here `b_j` and `g_j` are the "free parameters", with `a_j` and `aplus_j` are the columns of `A0` and `Aplus`. The cross `A0` - `Aplus` restrictions require `W[j]` to be non-zero.
The work will be going from the dynare file to producing `U[j]`, `V[j]`, and `W[j]`. You already produce `U[j]` and `V[j]`, so producing `W[j]` should not be to much more work.
After a user inquiry at http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=9594, @dwaggoner replied with the following. The question is now whether we want to implement this?
The underlying C code can handle linear restrictions across `A0` and `Aplus` as long as they are not cross-equation. Also the restrictions must be linear, not affine, i.e. no non-zero constant. It seems like this is what the person is asking for. Also, this cannot be used with the Sims-Zha specification as that requires `Aplus` to be unrestricted.
Each column (equation) of `A0` and Aplus can be restricted to be of the form
```
a_j = U[j]*b_j
aplus_j = V[j]*g_j + W[j]*a_j
```
Here `b_j` and `g_j` are the "free parameters", with `a_j` and `aplus_j` are the columns of `A0` and `Aplus`. The cross `A0` - `Aplus` restrictions require `W[j]` to be non-zero.
The work will be going from the dynare file to producing `U[j]`, `V[j]`, and `W[j]`. You already produce `U[j]` and `V[j]`, so producing `W[j]` should not be to much more work.
https://git.dynare.org/Dynare/dynare/issues/1055Deprecate first_obs and last_obs in data command2018-09-11T15:00:44ZStéphane Adjemianstepan@dynare.orgDeprecate first_obs and last_obs in data commandReplaced by `first_date` and `last_date`, to avoid confusion with the options in the `estimation` command.
Replaced by `first_date` and `last_date`, to avoid confusion with the options in the `estimation` command.
Stéphane Adjemianstepan@dynare.orgStéphane Adjemianstepan@dynare.orghttps://git.dynare.org/Dynare/dynare/issues/1044Clear up option mh_posterior_mode_estimation2018-09-11T15:00:44ZJohannes Pfeifer Clear up option mh_posterior_mode_estimationSee the question at http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=7235
Does anyone know what it does?
Looking at the codes in `dynare_estimation_1.m` this option seems to skip mode computation and directly runs the MCMC, using the prior mode as the starting point and the prior variances for computing the inverse Hessian for the MCMC. In case of the mode not existing, the prior mean is used.
But already before doing so, it sets
```
oo_.posterior.optimization.mode = xparam1;
oo_.posterior.optimization.Variance = [];
```
That is, the mode saved is based on the starting values given for MCMC and no variance is saved. This looks like a a bug as the MCMC starts with values that are only set after this assignment.
Finally, this option runs the MCMC and calls `CutSample.m` before returning. What is the point of just estimating the MCMC starting at the prior mode and providing no output?
We should either document the option and add a preprocessor command or get rid of it.
See the question at http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=7235
Does anyone know what it does?
Looking at the codes in `dynare_estimation_1.m` this option seems to skip mode computation and directly runs the MCMC, using the prior mode as the starting point and the prior variances for computing the inverse Hessian for the MCMC. In case of the mode not existing, the prior mean is used.
But already before doing so, it sets
```
oo_.posterior.optimization.mode = xparam1;
oo_.posterior.optimization.Variance = [];
```
That is, the mode saved is based on the starting values given for MCMC and no variance is saved. This looks like a a bug as the MCMC starts with values that are only set after this assignment.
Finally, this option runs the MCMC and calls `CutSample.m` before returning. What is the point of just estimating the MCMC starting at the prior mode and providing no output?
We should either document the option and add a preprocessor command or get rid of it.
https://git.dynare.org/Dynare/dynare/issues/819Support DSGE-VAR forecasts2018-09-11T15:00:44ZJohannes Pfeifer Support DSGE-VAR forecastsCurrently, forecasts are based on the DSGE model and not the DSGE-VAR
Currently, forecasts are based on the DSGE model and not the DSGE-VAR
https://git.dynare.org/Dynare/dynare/issues/1514Add Importance Ratio as diagnostic for checking accuracy of normal approximat...2018-09-11T15:00:44ZJohannes 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.6https://git.dynare.org/Dynare/dynare/issues/1045Clarify interface for evaluate_planner_objective.m2018-09-11T15:00:44ZMichelJuillardClarify interface for evaluate_planner_objective.mIt works OK for evaluation at the steady state, but the way to set histval and shocks in first period is confusing
It works OK for evaluation at the steady state, but the way to set histval and shocks in first period is confusing
MichelJuillardMichelJuillard