dynare issueshttps://git.dynare.org/Dynare/dynare/issues2019-11-21T08:36:45Zhttps://git.dynare.org/Dynare/dynare/issues/832Use dseries objects in Dynare2019-11-21T08:36:45ZStéphane Adjemianstepan@adjemian.euUse dseries objects in DynareIn the current state, `dseries` objects can be used in matlab scripts and in Dynare's mod file to create and manipulate datasets. The next step is to integrate more deeply the `dseries` class and Dynare. Whenever possible the output of Dynare will be `dseries` objects (IRFs, forecasts, ...) and also we will allow the use of `dseries` objects as inputs to Dynare's command (`data`, content of `initval`, data for conditional forecasts, ...).
- [ ] Document the `data` command (new data interface).
- [ ] Save results as `dseries` objects.
- [x] Polish and document the from-to-do syntax.
- [ ] Add the possibility to pass `dseries`to `initial``and``histval``commands.
In the current state, `dseries` objects can be used in matlab scripts and in Dynare's mod file to create and manipulate datasets. The next step is to integrate more deeply the `dseries` class and Dynare. Whenever possible the output of Dynare will be `dseries` objects (IRFs, forecasts, ...) and also we will allow the use of `dseries` objects as inputs to Dynare's command (`data`, content of `initval`, data for conditional forecasts, ...).
- [ ] Document the `data` command (new data interface).
- [ ] Save results as `dseries` objects.
- [x] Polish and document the from-to-do syntax.
- [ ] Add the possibility to pass `dseries`to `initial``and``histval``commands.
Stéphane Adjemianstepan@adjemian.euStéphane Adjemianstepan@adjemian.euhttps://git.dynare.org/Dynare/dynare/issues/642Support Dirichlet prior distribution2019-11-21T08:36:45ZHoutan 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.
https://git.dynare.org/Dynare/dynare/issues/1534Add documentation for SMM/GMM/IRF options2019-11-21T08:36: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/d52f13114d10fbe5fd4d263d5d0b9d7cfda787f6Johannes Pfeifer Johannes Pfeifer https://git.dynare.org/Dynare/dynare/issues/1060Add capabilities for pseudo out of sample forecasting2019-11-21T08:36: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
https://git.dynare.org/Dynare/dynare/issues/386k_order_perturbation MEX: error messages are uninformative2019-11-21T08:36:44ZMichelJuillardk_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.
Sébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/issues/349Use preprocessor for loglinearization2019-11-21T08:36:43ZJohannes 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.
https://git.dynare.org/Dynare/dynare/issues/1031declare all options_ fields as empty/0/NaN in global_initialization2019-11-21T08:36:43ZHoutan Bastanideclare all options_ fields as empty/0/NaN in global_initializationFollowing the discussion on pr #1030, we must decide whether or not we want to do this and implement it throughout the code (or not)
Following the discussion on pr #1030, we must decide whether or not we want to do this and implement it throughout the code (or not)
https://git.dynare.org/Dynare/dynare/issues/824Add an interface for joint priors.2019-11-21T08:36:43ZStéphane Adjemianstepan@adjemian.euAdd an interface for joint priors.Only available for the new estimation syntax. Something like:
``` example
[alpha, beta].prior(shape=gaussian, mean=Vector, variance=Matrix, ...)
```
This interface is needed for Dirichlet priors over probabilities.
Only available for the new estimation syntax. Something like:
``` example
[alpha, beta].prior(shape=gaussian, mean=Vector, variance=Matrix, ...)
```
This interface is needed for Dirichlet priors over probabilities.
Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/issues/7In dr.tex, add a concrete example on a model (by expliciting the matrices)2019-11-21T08:36:42ZSébastien VillemotIn dr.tex, add a concrete example on a model (by expliciting the matrices)https://git.dynare.org/Dynare/dynare/issues/133datafile option in simul2019-11-21T08:36:42ZSé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.
https://git.dynare.org/Dynare/dynare/issues/416Document how to do learning with Dynare2019-11-21T08:36:42ZJohannes 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
Stéphane Adjemianstepan@adjemian.euStéphane Adjemianstepan@adjemian.euhttps://git.dynare.org/Dynare/dynare/issues/877document set_time, estimation_data, subsamples, joint_prior, prior, std_prior...2019-11-21T08:36:42ZHoutan Bastanidocument set_time, estimation_data, subsamples, joint_prior, prior, std_prior, corr_prior, prior equal, options, std_options, corr_options, options equalStéphane Adjemianstepan@adjemian.euStéphane Adjemianstepan@adjemian.euhttps://git.dynare.org/Dynare/dynare/issues/1170Non-bayesian estimation should use quasi-Maximum likelihood standard errors2019-11-21T08:36:42ZTom 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.
Marco RattoMarco Rattohttps://git.dynare.org/Dynare/dynare/issues/831Improve homotopy2019-11-21T08:36:42ZStéphane Adjemianstepan@adjemian.euImprove 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`.
Stéphane Adjemianstepan@adjemian.euStéphane Adjemianstepan@adjemian.euhttps://git.dynare.org/Dynare/dynare/issues/339Clarify difference between Bayesian HPDI and classical confidence bands in ma...2019-11-21T08:36:42ZJohannes 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.
https://git.dynare.org/Dynare/dynare/issues/835Behavior of STEADY_STATE() in perfect foresight models with anticipated perma...2019-11-21T08:36:41ZStéphane Adjemianstepan@adjemian.euBehavior 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).
https://git.dynare.org/Dynare/dynare/issues/1414command options should be made local, and a new syntax should provide persist...2019-11-21T08:36:41ZHoutan Bastanicommand options should be made local, and a new syntax should provide persistent optionsAllow users the possibility to bypass the current situation where an option set in one command is perpetuated into other commands when the user doesn't explicitly pass the option again. e.g. In the following case, the second call to `command` will have options 1, 2, and 3 set even though only 1 and 3 were passed:
```
command(option1, option2);
command(option1, option3);
```
Introduce a new syntax such as
```
command(option1, option2);
command!(option1, option3);
```
which would tell the preprocessor to reset all command-specific options to their defaults before writing output. To do this, every command's options must be local to a substructure of `options_` (i.e. `options_.command.option1`, `options_.command.option2`, etc.)Allow users the possibility to bypass the current situation where an option set in one command is perpetuated into other commands when the user doesn't explicitly pass the option again. e.g. In the following case, the second call to `command` will have options 1, 2, and 3 set even though only 1 and 3 were passed:
```
command(option1, option2);
command(option1, option3);
```
Introduce a new syntax such as
```
command(option1, option2);
command!(option1, option3);
```
which would tell the preprocessor to reset all command-specific options to their defaults before writing output. To do this, every command's options must be local to a substructure of `options_` (i.e. `options_.command.option1`, `options_.command.option2`, etc.)Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/issues/827Feature request: Implement the algorithm of Ajevskis (2014) for perturbation ...2019-11-21T08:36:41ZTom HoldenFeature request: Implement the algorithm of Ajevskis (2014) for perturbation around a deterministic pathViktors Ajevskis has a [great new paper](https://ideas.repec.org/p/ltv/wpaper/201401.html) showing how the Lombardo pruning method may be extended to support perturbation around a deterministic path. This seems like a feature that would be a huge benefit to virtually all Dynare users, since it makes it possible to e.g.:
- Solve non-stationary DSGE models, such as those featuring structural change.
- Evaluate the welfare consequences of a permanent change in policy, without sacrificing accuracy along the transition path.
- Obtain increased accuracy for large impulse response exercises.
- Unify the stochastic and non-stochastic simulation engines in Dynare.
It would be great if this could be added to the bottom of your very long to do list!
https://ideas.repec.org/p/ltv/wpaper/201401.html
Viktors Ajevskis has a [great new paper](https://ideas.repec.org/p/ltv/wpaper/201401.html) showing how the Lombardo pruning method may be extended to support perturbation around a deterministic path. This seems like a feature that would be a huge benefit to virtually all Dynare users, since it makes it possible to e.g.:
- Solve non-stationary DSGE models, such as those featuring structural change.
- Evaluate the welfare consequences of a permanent change in policy, without sacrificing accuracy along the transition path.
- Obtain increased accuracy for large impulse response exercises.
- Unify the stochastic and non-stochastic simulation engines in Dynare.
It would be great if this could be added to the bottom of your very long to do list!
https://ideas.repec.org/p/ltv/wpaper/201401.html
https://git.dynare.org/Dynare/dynare/issues/568Integrate DMM2019-11-21T08:36:41ZHoutan 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
MichelJuillardMichelJuillardhttps://git.dynare.org/Dynare/dynare/issues/1162Handling of trends2019-11-21T08:36:41ZMichelJuillardHandling 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