dynare issueshttps://git.dynare.org/Dynare/dynare/issues2019-01-15T10:52:35Zhttps://git.dynare.org/Dynare/dynare/issues/1414command options should be made local, and a new syntax should provide persist...2019-01-15T10:52:35ZHoutan 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.)5.0Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/issues/1208updated2histval2018-11-08T10:17:14ZMarco Rattoupdated2histvalfor real time forecasting exercises, it would be useful a utility
`updated2histval`
with the same behavior as:
`smoother2histval`
but that uses `oo_.UpdatedVariables` in place of `oo_.SmoothedVariables`
would this be feasible?
for real time forecasting exercises, it would be useful a utility
`updated2histval`
with the same behavior as:
`smoother2histval`
but that uses `oo_.UpdatedVariables` in place of `oo_.SmoothedVariables`
would this be feasible?
5.0https://git.dynare.org/Dynare/dynare/issues/1204Crash in unstable mex when called from parallel workers2018-11-08T10:16:48ZTom 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.
5.0Stéphane Adjemianstepan@dynare.orgStéphane Adjemianstepan@dynare.orghttps://git.dynare.org/Dynare/dynare/issues/1173Support estimation under optimal policy2019-09-20T06:36:13ZJohannes Pfeifer Support estimation under optimal policySee http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=8071
See http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=8071
5.0https://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/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/1114create contributions.md describing how to contribute to dynare2018-11-08T11:54:36ZHoutan Bastanicreate contributions.md describing how to contribute to dynare5.0Stéphane Adjemianstepan@dynare.orgStéphane Adjemianstepan@dynare.orghttps://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/1078Make lyapunov_symm compatible with sparse matrices2018-11-08T10:30:59ZJohannes Pfeifer Make lyapunov_symm compatible with sparse matricesAs discussed in #988 it would make sense to have `lyapunov_symm` able to work with sparse matrices (at least for the baseline option)
As discussed in #988 it would make sense to have `lyapunov_symm` able to work with sparse matrices (at least for the baseline option)
5.0https://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/1031declare all options_ fields as empty/0/NaN in global_initialization2018-11-08T10:31:31ZHoutan 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)
5.0https://git.dynare.org/Dynare/dynare/issues/1004Make initvalf and histvalf compatible with translation to one-lag problem2018-09-11T15:00:44ZJohannes 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
5.0https://git.dynare.org/Dynare/dynare/issues/915Integrate convert_dyn_45_to_44 into convert_oo_.m2018-09-11T15:00:44ZJohannes 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
5.0Johannes Pfeifer Johannes Pfeifer https://git.dynare.org/Dynare/dynare/issues/877document set_time, estimation_data, subsamples, joint_prior, prior, std_prior...2018-11-08T10:32:11ZHoutan Bastanidocument set_time, estimation_data, subsamples, joint_prior, prior, std_prior, corr_prior, prior equal, options, std_options, corr_options, options equal5.0Stéphane Adjemianstepan@dynare.orgStéphane Adjemianstepan@dynare.orghttps://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/832Use dseries objects in Dynare2018-11-08T10:31:52ZStéphane Adjemianstepan@dynare.orgUse 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.
5.0Stéphane Adjemianstepan@dynare.orgStéphane Adjemianstepan@dynare.orghttps://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/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/827Feature request: Implement the algorithm of Ajevskis (2014) for perturbation ...2019-08-14T12:15:53ZTom 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
5.0https://git.dynare.org/Dynare/dynare/issues/824Add an interface for joint priors.2018-11-08T10:32:51ZStéphane Adjemianstepan@dynare.orgAdd 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.
5.0Houtan BastaniHoutan Bastani