dynare issueshttps://git.dynare.org/Dynare/dynare/-/issues2018-11-08T09:59:51Zhttps://git.dynare.org/Dynare/dynare/-/issues/1611Make dynare_sensitivity compatible with recursive estimation or provide infor...2018-11-08T09:59:51ZJohannes Pfeifer Make dynare_sensitivity compatible with recursive estimation or provide informative errorSee https://forum.dynare.org/t/calculating-rmses/11903 See https://forum.dynare.org/t/calculating-rmses/11903 https://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/1603Investigate whether var_exo_det works correctly with stoch_simul2021-01-12T14:03:41ZJohannes 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/1597Accept UTF-8 in .mod file2020-05-07T17:45:03ZHoutan BastaniAccept UTF-8 in .mod filehttps://git.dynare.org/Dynare/dynare/-/issues/1596add maximum lag info by variable2020-05-07T17:45:37ZHoutan Bastaniadd maximum lag info by variable```
M_.maximum_endo_lag_by_var = [ ... ];
M_.maximum_exo_lag_by_var = [ ... ];
```
Where the vectors are the length of `M_.orig_endo_nbr````
M_.maximum_endo_lag_by_var = [ ... ];
M_.maximum_exo_lag_by_var = [ ... ];
```
Where the vectors are the length of `M_.orig_endo_nbr`https://git.dynare.org/Dynare/dynare/-/issues/1593Add truncated priors2018-11-08T10:09:48ZJohannes Pfeifer Add truncated priorsFollowing the discussions in #1591 and #750, we currently do not have a way to introduce a proper truncated prior. But this is an often requested feature thta e.g. @rattoma would like to have. Waiting for the new estimation interface (e.g. #824 and #846) seems to long to wait.
My specific proposal would be to add a new token `truncated_norm_pdf` that uses the third and fourth hyperparameter (which is usually reserved for generalized (beta) distributions) to specify the truncation. I consider this a natural interpretation of these hyperparameters for the normal distribution.
@stepan-a What do you think?
@rattoma Woud that satisfy your immediate needs? Or do you need a truncated distribution other than the normal?Following the discussions in #1591 and #750, we currently do not have a way to introduce a proper truncated prior. But this is an often requested feature thta e.g. @rattoma would like to have. Waiting for the new estimation interface (e.g. #824 and #846) seems to long to wait.
My specific proposal would be to add a new token `truncated_norm_pdf` that uses the third and fourth hyperparameter (which is usually reserved for generalized (beta) distributions) to specify the truncation. I consider this a natural interpretation of these hyperparameters for the normal distribution.
@stepan-a What do you think?
@rattoma Woud that satisfy your immediate needs? Or do you need a truncated distribution other than the normal?Stéphane Adjemianstepan@adjemian.euStéphane Adjemianstepan@adjemian.euhttps://git.dynare.org/Dynare/dynare/-/issues/1573Allow mode_compute to be a vector2020-11-13T12:37:07ZJohannes Pfeifer Allow mode_compute to be a vectorAllow `mode_compute` to be a vector and the sequentially execute the mode-finders specified. See e.g. https://forum.dynare.org/t/simulated-annealing-block/11052 for why this may be useful.Allow `mode_compute` to be a vector and the sequentially execute the mode-finders specified. See e.g. https://forum.dynare.org/t/simulated-annealing-block/11052 for why this may be useful.https://git.dynare.org/Dynare/dynare/-/issues/1556Allow running mode-finding on random draws from prior distribution to check f...2018-11-08T10:13:54ZJohannes Pfeifer Allow running mode-finding on random draws from prior distribution to check for local modeshttps://git.dynare.org/Dynare/dynare/-/issues/1400Investigate dseries problems in parallel execution2018-11-08T10:15:22ZJohannes Pfeifer Investigate dseries problems in parallel executionWhen executing the attached file, which runs the ```UseParallel``` feature of ```fmincon```, a crash results because the dseries data is transformed to a structure:
```
Warning: Element(s) of class 'dseries' do not match the current constructor definition. The element(s) have been converted to structures.
> In parallel.internal.pool.deserialize (line 9)
In parallel.internal.pool.deserializeFunction (line 12)
In remoteParallelFunction (line 33)
Warning: Element(s) of class 'dates' do not match the current constructor definition. The element(s) have been converted to structures.
> In parallel.internal.pool.deserialize (line 9)
In parallel.internal.pool.deserializeFunction (line 12)
In remoteParallelFunction (line 33)
```
[SW.zip](https://github.com/DynareTeam/dynare/files/827628/SW.zip)
When executing the attached file, which runs the ```UseParallel``` feature of ```fmincon```, a crash results because the dseries data is transformed to a structure:
```
Warning: Element(s) of class 'dseries' do not match the current constructor definition. The element(s) have been converted to structures.
> In parallel.internal.pool.deserialize (line 9)
In parallel.internal.pool.deserializeFunction (line 12)
In remoteParallelFunction (line 33)
Warning: Element(s) of class 'dates' do not match the current constructor definition. The element(s) have been converted to structures.
> In parallel.internal.pool.deserialize (line 9)
In parallel.internal.pool.deserializeFunction (line 12)
In remoteParallelFunction (line 33)
```
[SW.zip](https://github.com/DynareTeam/dynare/files/827628/SW.zip)
Stéphane Adjemianstepan@adjemian.euStéphane Adjemianstepan@adjemian.euhttps://git.dynare.org/Dynare/dynare/-/issues/1173Support estimation under optimal policy2021-04-01T11:10:14ZJohannes 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
4.7Sébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/846Provide inverse gamma prior with indeterminate moments2018-11-08T10:32:21ZJohannes Pfeifer Provide inverse gamma prior with indeterminate momentsWe currently only allow specifying inverse gamma priors with finite/unique mean and variance. But Leeper/Walker/Yang (2010) in an influential paper use an inverse gamma prior with s=1 and nu=4 (parametrization as at http://en.wikipedia.org/wiki/Inverse-gamma_distribution), which implies non-existing first and second moments. I would suggest to provide a new prior `inv_gamma_parametrized` that takes the values provided in the mean and standard deviation fields of the `estimated_params`-block directly as the parameters of the distribution, thereby avoiding the impossible transformation from mean and variances.
I would implement this when doing #520
We currently only allow specifying inverse gamma priors with finite/unique mean and variance. But Leeper/Walker/Yang (2010) in an influential paper use an inverse gamma prior with s=1 and nu=4 (parametrization as at http://en.wikipedia.org/wiki/Inverse-gamma_distribution), which implies non-existing first and second moments. I would suggest to provide a new prior `inv_gamma_parametrized` that takes the values provided in the mean and standard deviation fields of the `estimated_params`-block directly as the parameters of the distribution, thereby avoiding the impossible transformation from mean and variances.
I would implement this when doing #520
https://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/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/1540create reports for dynare commands2020-05-07T17:45:44ZHoutan Bastanicreate reports for dynare commandsCreate standardized reporting output for dynare commands using the reporting submodule, replacing latex code throughout the dynare codebaseCreate standardized reporting output for dynare commands using the reporting submodule, replacing latex code throughout the dynare codebasehttps://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
https://git.dynare.org/Dynare/dynare/-/issues/1114create contributions.md describing how to contribute to dynare2020-12-08T13:51:42ZHoutan Bastanicreate contributions.md describing how to contribute to dynare4.7Stéphane Adjemianstepan@adjemian.euStéphane Adjemianstepan@adjemian.euhttps://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/1112homogeneize treatment of leads/lags on exogenous between deterministic and st...2021-01-13T18:50:40ZHoutan Bastanihomogeneize treatment of leads/lags on exogenous between deterministic and stochastic modesAuxiliary 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.4.7Sébastien VillemotSébastien Villemothttps://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/829Rewrite local_state_space_iteration_2 routine2021-01-13T13:25:07ZStéphane Adjemianstepan@adjemian.euRewrite local_state_space_iteration_2 routineSeparate the measurement and state equations. See discussions in [particles](https://git.dynare.org/Dynare/particles/-/issues) repository.Separate the measurement and state equations. See discussions in [particles](https://git.dynare.org/Dynare/particles/-/issues) repository.Stéphane Adjemianstepan@adjemian.euStéphane Adjemianstepan@adjemian.euhttps://git.dynare.org/Dynare/dynare/-/issues/1532Factorize IRF code into function generate_irfs(M_,options_,oo_)2018-11-08T10:14:41ZJohannes Pfeifer Factorize IRF code into function generate_irfs(M_,options_,oo_)Take the fragmented codes from `stoch_simul` and `PosteriorIRFcore1` and put them into one function that is used in those other commands, but can also be called as a standalone. Related to #1531. Take the fragmented codes from `stoch_simul` and `PosteriorIRFcore1` and put them into one function that is used in those other commands, but can also be called as a standalone. Related to #1531. https://git.dynare.org/Dynare/dynare/-/issues/1078Make lyapunov_symm compatible with sparse matrices2019-11-21T08:36:41ZJohannes 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)
https://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/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/1521create class for storing/writing metropolis draws2019-12-20T16:31:36ZHoutan Bastanicreate class for storing/writing metropolis drawsIn the `while` loop of `matlab/posterior_sampler_core.m` we have an example of how draws are stored and written when a certain number of draws have been stored in memory.
Need to create a Matlab class that stores:
- a vector
- a matrix
- a structure (`dr`)
And that writes itself to disk when a certain number of vector/matrix/structures have been written and clears itself so that more draws can be stored.
This class can then be used to standardize the various ways we do this throughout the Matlab codebase.In the `while` loop of `matlab/posterior_sampler_core.m` we have an example of how draws are stored and written when a certain number of draws have been stored in memory.
Need to create a Matlab class that stores:
- a vector
- a matrix
- a structure (`dr`)
And that writes itself to disk when a certain number of vector/matrix/structures have been written and clears itself so that more draws can be stored.
This class can then be used to standardize the various ways we do this throughout the Matlab codebase.4.7https://git.dynare.org/Dynare/dynare/-/issues/1056Document the data command2018-09-11T15:00:44ZStéphane Adjemianstepan@adjemian.euDocument the data commandStéphane Adjemianstepan@adjemian.euStéphane Adjemianstepan@adjemian.euhttps://git.dynare.org/Dynare/dynare/-/issues/1055Deprecate first_obs and last_obs in data command2018-09-11T15:00:44ZStéphane Adjemianstepan@adjemian.euDeprecate 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@adjemian.euStéphane Adjemianstepan@adjemian.euhttps://git.dynare.org/Dynare/dynare/-/issues/824Add an interface for joint priors.2020-05-07T17:47:17ZSté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.
https://git.dynare.org/Dynare/dynare/-/issues/1514Add Importance Ratio as diagnostic for checking accuracy of normal approximat...2019-12-20T16:31:49ZJohannes 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.7https://git.dynare.org/Dynare/dynare/-/issues/1044Clear up option mh_posterior_mode_estimation2020-12-15T12:34:33ZJohannes 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/1513Allow selecting proper training sample for endogenous_prior2019-12-20T16:32:01ZJohannes Pfeifer Allow selecting proper training sample for endogenous_priorCurrently, we simply use `Y=data';`, but it is straightforward to include different dataCurrently, we simply use `Y=data';`, but it is straightforward to include different data4.7https://git.dynare.org/Dynare/dynare/-/issues/1045Clarify interface for evaluate_planner_objective.m2020-03-02T10:03:52ZMichelJuillardClarify 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
MichelJuillardMichelJuillardhttps://git.dynare.org/Dynare/dynare/-/issues/1031declare all options_ fields as empty/0/NaN in global_initialization2021-01-20T10:05:50ZHoutan 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/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/978Fix interface/options for stochastic extended path in master2019-04-01T07:09:38ZJohannes Pfeifer Fix interface/options for stochastic extended path in masterNot all required options are set by default. For example, `rs2.mod` needs to manually set
```
options_.ep.IntegrationAlgorithm='UT_2p+1';
```
as otherwise a crash in `setup_integration_nodes.m` happens. We should properly initialize all options and add a unit test that tests the default options.
Not all required options are set by default. For example, `rs2.mod` needs to manually set
```
options_.ep.IntegrationAlgorithm='UT_2p+1';
```
as otherwise a crash in `setup_integration_nodes.m` happens. We should properly initialize all options and add a unit test that tests the default options.
MichelJuillardMichelJuillardhttps://git.dynare.org/Dynare/dynare/-/issues/713Block recursive prior definitions2018-09-11T15:00:44ZJohannes Pfeifer Block recursive prior definitionsRecursive specification of priors seem to be currently allowed, e.g.
```
a1 0.2,1E-5,1, BETA_PDF,0.5,0.1;
a2 0.5,1E-5,1, a1 BETA_PDF,0.85,0.1;
```
where the upper bound for `a2` is actually set based on the value `a1` has in the parameter initialization section (and never updates it during estimation based on new values of `a1`). But the user clearly intends to make the prior conditional, which Dynare does not allow. We should block this kind of behavior in the preprocessor, because the actual behavior is unexpected.
Sidenote: would it be sensible to allow for conditional priors at some point in the future?
Recursive specification of priors seem to be currently allowed, e.g.
```
a1 0.2,1E-5,1, BETA_PDF,0.5,0.1;
a2 0.5,1E-5,1, a1 BETA_PDF,0.85,0.1;
```
where the upper bound for `a2` is actually set based on the value `a1` has in the parameter initialization section (and never updates it during estimation based on new values of `a1`). But the user clearly intends to make the prior conditional, which Dynare does not allow. We should block this kind of behavior in the preprocessor, because the actual behavior is unexpected.
Sidenote: would it be sensible to allow for conditional priors at some point in the future?
https://git.dynare.org/Dynare/dynare/-/issues/933Add load_mh_file-like option for loading posterior subdraws2018-09-11T15:00:44ZJohannes Pfeifer Add load_mh_file-like option for loading posterior subdrawsSee #566
See #566
https://git.dynare.org/Dynare/dynare/-/issues/709Preprocessor: Allow reusage of model local variable names in steady_state_mod...2018-09-11T15:00:44ZTom HoldenPreprocessor: Allow reusage of model local variable names in steady_state_model block (wishlist)At present, variables with the same name as model local variables cannot be created in the `steady_state_model` block. It would be very nice if the preprocessor to a C style approach to variable scope, and allowed the creation of variables with the same name in different blocks, when neither block contains the other. An example of quite why this would be useful follows:
An operation I find myself performing frequently is replacing e.g. the endogenous variable `Y` with the endogenous variable `log_Y`. I then create a model local variable for `Y` via `#Y = exp( log_Y );`. Ideally, I should just have to add the line `log_Y = log( Y );` to the end of the `steady_state_model` block for the new `.mod` file to run. However, just doing this produces an error since I'm now using `Y` as a temporary variable within the `steady_state_model` block. Thus I have to make assorted modifications to the `steady_state_model` block to first remove all references to `Y`.
For an example of this in practice, see `example.mod` in https://github.com/tholden/DynareTransformationEngine , which is a repository for making such transformations automatically, chiefly produced as an example of what is possible with the preprocessor. This runs at present, but doesn't if you remove the suffix underscores from the `steady_state_model` block.
At present, variables with the same name as model local variables cannot be created in the `steady_state_model` block. It would be very nice if the preprocessor to a C style approach to variable scope, and allowed the creation of variables with the same name in different blocks, when neither block contains the other. An example of quite why this would be useful follows:
An operation I find myself performing frequently is replacing e.g. the endogenous variable `Y` with the endogenous variable `log_Y`. I then create a model local variable for `Y` via `#Y = exp( log_Y );`. Ideally, I should just have to add the line `log_Y = log( Y );` to the end of the `steady_state_model` block for the new `.mod` file to run. However, just doing this produces an error since I'm now using `Y` as a temporary variable within the `steady_state_model` block. Thus I have to make assorted modifications to the `steady_state_model` block to first remove all references to `Y`.
For an example of this in practice, see `example.mod` in https://github.com/tholden/DynareTransformationEngine , which is a repository for making such transformations automatically, chiefly produced as an example of what is possible with the preprocessor. This runs at present, but doesn't if you remove the suffix underscores from the `steady_state_model` block.
https://git.dynare.org/Dynare/dynare/-/issues/1208updated2histval2019-11-21T08:36:40ZMarco 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?
https://git.dynare.org/Dynare/dynare/-/issues/909Create true unit test from comments in middle of random_walk_metropolis_hasti...2018-09-11T15:00:44ZJohannes Pfeifer Create true unit test from comments in middle of random_walk_metropolis_hastings.mThere is some advice for a manual unit test hidden there.
There is some advice for a manual unit test hidden there.
https://git.dynare.org/Dynare/dynare/-/issues/891adding options to irf/moment calibration2018-09-11T15:00:44ZMarco Rattoadding options to irf/moment calibrationWould it be possible to add options in the irf/moment calibration interface.
For example it would be good to allow:
```
irf_calibration(relative_irf);
...
end;
```
to allow triggering
`options_.relative_irf=1;`
In fact, when std of shocks are estimated, it makes probably more sense to target a relative response w.r.t. an absolute one, which might just change due to the change in the value of the shock.
Similarly, we might think of allowing `moment_calibration` to trigger estimation type options, like
```
varobs y_obs R_obs pie_obs dq de;
moment_calibration(datafile='data_ca1.m',first_obs=8,nobs=79,prefilter=1,ar=1);
...
end;
```
that would allow me to write a routine that automatically generates data based moment restrictions up to lag `ar` for theoretical moments of the variables listed in `varobs`.
We might also allow a different list of variables for calibration w.r.t. estimation, e.g. by
```
varobs_calibration y_obs R_obs pie_obs dq de;
```
Or by adding the list of variables inside the `moment_calibration` command (like `namendo` comma separated list in sensitivity analysis)
```
moment_calibration( datafile='data_ca1.m',first_obs=8,nobs=79,prefilter=1,ar=1,
varobs=(y_obs, R_obs, pie_obs, dq de)
);
...
end;
```
what do you think?
Would it be possible to add options in the irf/moment calibration interface.
For example it would be good to allow:
```
irf_calibration(relative_irf);
...
end;
```
to allow triggering
`options_.relative_irf=1;`
In fact, when std of shocks are estimated, it makes probably more sense to target a relative response w.r.t. an absolute one, which might just change due to the change in the value of the shock.
Similarly, we might think of allowing `moment_calibration` to trigger estimation type options, like
```
varobs y_obs R_obs pie_obs dq de;
moment_calibration(datafile='data_ca1.m',first_obs=8,nobs=79,prefilter=1,ar=1);
...
end;
```
that would allow me to write a routine that automatically generates data based moment restrictions up to lag `ar` for theoretical moments of the variables listed in `varobs`.
We might also allow a different list of variables for calibration w.r.t. estimation, e.g. by
```
varobs_calibration y_obs R_obs pie_obs dq de;
```
Or by adding the list of variables inside the `moment_calibration` command (like `namendo` comma separated list in sensitivity analysis)
```
moment_calibration( datafile='data_ca1.m',first_obs=8,nobs=79,prefilter=1,ar=1,
varobs=(y_obs, R_obs, pie_obs, dq de)
);
...
end;
```
what do you think?
https://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/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/1414command options should be made local, and a new syntax should provide persist...2020-05-07T17:45:59ZHoutan 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.)https://git.dynare.org/Dynare/dynare/-/issues/630Improving Ramsey computations2021-01-28T09:15:36ZMichelJuillardImproving Ramsey computations- [ ] adding the possibility to use one of the parameters of the model as the planner_discount factor
- [x] give independent access to the fonction evaluating the objective function- [ ] adding the possibility to use one of the parameters of the model as the planner_discount factor
- [x] give independent access to the fonction evaluating the objective functionMichelJuillardMichelJuillardhttps://git.dynare.org/Dynare/dynare/-/issues/1407Keep track of whether smoother results are in logs and adjust smoother2histva...2020-12-08T13:50:43ZJohannes Pfeifer Keep track of whether smoother results are in logs and adjust smoother2histval accordinglySee !1396See !13964.7https://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/569Integrate OccBin2021-05-06T15:34:42ZHoutan 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
4.7Marco RattoMarco Rattohttps://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/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/526Support the estimation of static models2018-11-08T11:49:07ZJohannes Pfeifer Support the estimation of static modelsSee http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=5120
It seems not all variables are correctly initialized
See http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=5120
It seems not all variables are correctly initialized
https://git.dynare.org/Dynare/dynare/-/issues/1643Implement pruning at order>32021-01-21T16:23:44ZJohannes 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.8Normann RionNormann Rionhttps://git.dynare.org/Dynare/dynare/-/issues/444Document nonlinear filters2021-05-06T11:34:13ZStéphane Adjemianstepan@adjemian.euDocument nonlinear filtersWe need to describe and discuss all the available options in `options_.particle` (there is still no interface for these options because the set of options is not yet stable).We need to describe and discuss all the available options in `options_.particle` (there is still no interface for these options because the set of options is not yet stable).4.7Stéphane Adjemianstepan@adjemian.euStéphane Adjemianstepan@adjemian.euhttps://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/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 variable transformation (e.g. exp for doing approximatio...2020-12-23T12:53:54ZJohannes Pfeifer Use preprocessor for variable transformation (e.g. exp for doing approximation in log variables instead of level variables)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.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.4.7https://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/326Change color scheme of figures to be readable on monochrome printouts2019-06-19T15:37:41ZJohannes Pfeifer Change color scheme of figures to be readable on monochrome printoutsMore information will be provided soon.
More information will be provided soon.
https://git.dynare.org/Dynare/dynare/-/issues/312Allow User to choose Mean or Median statistics2019-06-19T15:37:41ZJohannes Pfeifer Allow User to choose Mean or Median statisticsCurrently the posterior IRFs make hardcoded use of the Mean IRFs,although we also compute the median. It might be good to let the user decide. This mainly affects PosteriorIRF and PosteriorIRF_core2, but could also be relevant at other places in the code.
Currently the posterior IRFs make hardcoded use of the Mean IRFs,although we also compute the median. It might be good to let the user decide. This mainly affects PosteriorIRF and PosteriorIRF_core2, but could also be relevant at other places in the code.
https://git.dynare.org/Dynare/dynare/-/issues/300Implement k-order derivatives of external functions2019-12-16T14:00:55ZSébastien VillemotImplement k-order derivatives of external functionsOtherwise order ≥ 3 fails with a cryptic preprocessor error
Otherwise order ≥ 3 fails with a cryptic preprocessor error
4.7https://git.dynare.org/Dynare/dynare/-/issues/295offer a quiet and a verbose mode2019-06-19T15:37:41ZSébastien Villemotoffer a quiet and a verbose modeSome users who run Dynare in a loop would like to suppress all messages. On the contrary, some want more messages, for example when debugging.
We currently have a way to disable warnings (see #301). Error messages should probably never be disabled.
For normal messages, we currently have the `noprint` option, but it is limited to some commands only.
I think we should provide three (global) levels of verbosity:
- a quiet mode, with nothing printed (except warnings and error messages)
- a normal mode
- a verbose mode (with some debug messages or more details)
The quiet and verbose modes should probably map to equivalent options of the `dynare` command.
The quiet option could set `options_.noprint=1` internally. The verbose option could set `options_.verbose=1`. Of course one can't have both quiet and verbose set at the same time.
We may want to deprecate the `noprint` options given at the command level. The problem is that if `verbose` is set at the global level, then a `noprint` at a local level would create many problems (in particular because all options have a global effect).
Then we have to modify the preprocessor, all M-files and MEX files to obey these two settings.
Some users who run Dynare in a loop would like to suppress all messages. On the contrary, some want more messages, for example when debugging.
We currently have a way to disable warnings (see #301). Error messages should probably never be disabled.
For normal messages, we currently have the `noprint` option, but it is limited to some commands only.
I think we should provide three (global) levels of verbosity:
- a quiet mode, with nothing printed (except warnings and error messages)
- a normal mode
- a verbose mode (with some debug messages or more details)
The quiet and verbose modes should probably map to equivalent options of the `dynare` command.
The quiet option could set `options_.noprint=1` internally. The verbose option could set `options_.verbose=1`. Of course one can't have both quiet and verbose set at the same time.
We may want to deprecate the `noprint` options given at the command level. The problem is that if `verbose` is set at the global level, then a `noprint` at a local level would create many problems (in particular because all options have a global effect).
Then we have to modify the preprocessor, all M-files and MEX files to obey these two settings.
https://git.dynare.org/Dynare/dynare/-/issues/294rework option handling2020-05-07T17:47:23ZSé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.
https://git.dynare.org/Dynare/dynare/-/issues/285Allow user-specified path for exogenous in extended_path2019-06-19T15:37:42ZSébastien VillemotAllow user-specified path for exogenous in extended_pathThat could be implemented with the shocks blocks.
That could be implemented with the shocks blocks.
https://git.dynare.org/Dynare/dynare/-/issues/248Add tests for the parallelization engine2019-06-19T15:37:42ZSébastien VillemotAdd tests for the parallelization engineMarco RattoMarco Rattohttps://git.dynare.org/Dynare/dynare/-/issues/240rewrite getPowerDeriv assignments in temporary terms2019-06-19T15:37:42ZSébastien Villemotrewrite getPowerDeriv assignments in temporary termsFrom Stephane:
In models with power functions of the form x**a (utility functions, production functions, agregation functions, quadratic costs, ...) the evaluation of the jacobian matrix (or higher order derivates) necessitate potentially a huge number of calls to the routine getPowerDeriv (the name of the routine is explicit enough). In my example (a real business cycle model with perfect foresight) most of the time is spent in this routine, while, if my understanding is correct, this is not necessary because x>0.
I wrote a mex file (see the new branch called mex-!GetPowerDeriv) as a replacement for the matlab routine, unfortunatly the overhead cost is so high that the use of the mex file increases the total time of execution!
In my case I resolved the issue by using option use_dll, but this is not a solution for the majority of our users (they would have to install cygwin/gcc and configure matlab/mex). So my question is: Do we really need to call this routine in all situations ? Would it not be possible to replace calls to this routine by something like:
if (abs(x)>1e-12)
tmp = ANALYTICAL_EXPRESSION_OF_THE_DERIVATIVEx,params;
else
tmp = 0;
end
From Stephane:
In models with power functions of the form x**a (utility functions, production functions, agregation functions, quadratic costs, ...) the evaluation of the jacobian matrix (or higher order derivates) necessitate potentially a huge number of calls to the routine getPowerDeriv (the name of the routine is explicit enough). In my example (a real business cycle model with perfect foresight) most of the time is spent in this routine, while, if my understanding is correct, this is not necessary because x>0.
I wrote a mex file (see the new branch called mex-!GetPowerDeriv) as a replacement for the matlab routine, unfortunatly the overhead cost is so high that the use of the mex file increases the total time of execution!
In my case I resolved the issue by using option use_dll, but this is not a solution for the majority of our users (they would have to install cygwin/gcc and configure matlab/mex). So my question is: Do we really need to call this routine in all situations ? Would it not be possible to replace calls to this routine by something like:
if (abs(x)>1e-12)
tmp = ANALYTICAL_EXPRESSION_OF_THE_DERIVATIVEx,params;
else
tmp = 0;
end
https://git.dynare.org/Dynare/dynare/-/issues/237Document sbvar command2019-11-21T08:36:41ZSébastien VillemotDocument sbvar commandMichelJuillardMichelJuillardhttps://git.dynare.org/Dynare/dynare/-/issues/226New estimation2019-06-19T15:37:42ZSébastien VillemotNew estimationWrite the new estimation interface in the preprocessor. A description of what is needed is given on the wiki (http://www.dynare.org/DynareWiki/NewEstimation).
Write the new estimation interface in the preprocessor. A description of what is needed is given on the wiki (http://www.dynare.org/DynareWiki/NewEstimation).
Stéphane Adjemianstepan@adjemian.euStéphane Adjemianstepan@adjemian.euhttps://git.dynare.org/Dynare/dynare/-/issues/172improve derivation engine for derivatives of STEADY_STATE wrt parameters2019-06-19T15:37:42ZSébastien Villemotimprove derivation engine for derivatives of STEADY_STATE wrt parametersCurrently the derivatives of STEADY_STATE operator wrt to parameters are not handled in an efficient way, because the preprocessor does not exploit the a priori information for identifying null derivatives. This results in huge files for not so complicated models, which cannot be exploited by identification routines.
The proposal is to implement an algorithm in the preprocessor for identifying null derivatives ex ante:
- Create a non-directed graph whose nodes are the endogenous variables and the parameters
- For each pair of nodes, add an edge between the two if there is an equation in the static model containing both corresponding symbols (endogenous/parameters)
- For each endogenous, its derivative wrt a parameter is always zero if there is no path between the node representing the endogenous and the node representing the parameter.
Currently the derivatives of STEADY_STATE operator wrt to parameters are not handled in an efficient way, because the preprocessor does not exploit the a priori information for identifying null derivatives. This results in huge files for not so complicated models, which cannot be exploited by identification routines.
The proposal is to implement an algorithm in the preprocessor for identifying null derivatives ex ante:
- Create a non-directed graph whose nodes are the endogenous variables and the parameters
- For each pair of nodes, add an edge between the two if there is an equation in the static model containing both corresponding symbols (endogenous/parameters)
- For each endogenous, its derivative wrt a parameter is always zero if there is no path between the node representing the endogenous and the node representing the parameter.
https://git.dynare.org/Dynare/dynare/-/issues/163Finish first version of internal documentation2019-06-19T15:37:43ZSébastien VillemotFinish first version of internal documentationSee doc/internals/dynare-internals.org for the first draft.
For the IMF.
See doc/internals/dynare-internals.org for the first draft.
For the IMF.
https://git.dynare.org/Dynare/dynare/-/issues/162Global method: stochastic simulation approach2019-06-19T15:37:43ZSébastien VillemotGlobal method: stochastic simulation approachAs advocated by Judd, Maliar & Maliar in recent NBER WP.
For the IMF.
As advocated by Judd, Maliar & Maliar in recent NBER WP.
For the IMF.
https://git.dynare.org/Dynare/dynare/-/issues/149Handle missing values in block decomposed version of Kalman filter2019-06-19T15:37:43ZSébastien VillemotHandle missing values in block decomposed version of Kalman filterhttps://git.dynare.org/Dynare/dynare/-/issues/147Accuracy checks2019-11-21T08:36:40ZSébastien VillemotAccuracy checkshttps://git.dynare.org/Dynare/dynare/-/issues/135Improve display of decision rules with EXPECTATION operator2019-11-21T08:36:45ZSé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.
https://git.dynare.org/Dynare/dynare/-/issues/116IRF: give the possibility to choose the starting point (at least at order 2 a...2020-05-18T13:05:10ZSé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
https://git.dynare.org/Dynare/dynare/-/issues/115IRF: add the possibility to change the size of the shocks in the computations2020-05-18T13:05:11ZSé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.
https://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/1657add shock decomposition for forecasts done after estimation2021-01-21T15:56:53ZSébastien Villemotadd shock decomposition for forecasts done after estimation@MichelJuillard has some preliminary codes.@MichelJuillard has some preliminary codes.4.8Sébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/1658Write a howto on forecasting2019-09-20T13:06:55ZSébastien VillemotWrite a howto on forecastinghttps://git.dynare.org/Dynare/dynare/-/issues/1660Update documentation of dseries2021-01-21T15:53:26ZSébastien VillemotUpdate documentation of dseriesSince dseries have been substantially rewritten since 4.5, the documentation in the reference needs to be updated.Since dseries have been substantially rewritten since 4.5, the documentation in the reference needs to be updated.4.7Stéphane Adjemianstepan@adjemian.euStéphane Adjemianstepan@adjemian.euhttps://git.dynare.org/Dynare/dynare/-/issues/1663datafile option in perfect_foresight_setup: incomplete documentation and not ...2020-11-13T14:22:21ZMichelJuillarddatafile option in perfect_foresight_setup: incomplete documentation and not flexible enoughthe datafile option in perfect_foresight solver requires a text file without variable names, variables being order in order of VAR statement. The file name must end with ``_endo.dat``.
- [x] make loading data for guess value more flexible
- [x] honor INITVAL_FILE command or deprecate it
- [ ] make possible to use guess values with simul_backward-modelthe datafile option in perfect_foresight solver requires a text file without variable names, variables being order in order of VAR statement. The file name must end with ``_endo.dat``.
- [x] make loading data for guess value more flexible
- [x] honor INITVAL_FILE command or deprecate it
- [ ] make possible to use guess values with simul_backward-model4.7https://git.dynare.org/Dynare/dynare/-/issues/1664Implement option to use LMMCP for steady state computation2019-11-09T17:37:42ZMichelJuillardImplement option to use LMMCP for steady state computationIntroducing mixed complementarity problems in steady state computation may be useful to exclude parts of the definition space where no solution exists. It may also help when one doesn't know whether an occasionally binding constraints bites at the steady state or not, depending on the value of the parameters.Introducing mixed complementarity problems in steady state computation may be useful to exclude parts of the definition space where no solution exists. It may also help when one doesn't know whether an occasionally binding constraints bites at the steady state or not, depending on the value of the parameters.https://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/1674Modification to shock_decomposition and plot_decomposition interfaces to incl...2020-10-15T15:23:40ZDóra Kocsiskocsis.doralinda@gmail.comModification to shock_decomposition and plot_decomposition interfaces to include flexibility with datesInclude the following options for dates when shock_decomposition is triggered:
* date of the start of the decomposition, default: start of the estimation sample (some people may want to start the decomposition with the smoothed value at the end of the sample). Proposed option name: `init_date = INTEGER`.
* date of the start of the graph, default: start of the estimation sample. Proposed option name: `graph_init_date = INTEGER`.Include the following options for dates when shock_decomposition is triggered:
* date of the start of the decomposition, default: start of the estimation sample (some people may want to start the decomposition with the smoothed value at the end of the sample). Proposed option name: `init_date = INTEGER`.
* date of the start of the graph, default: start of the estimation sample. Proposed option name: `graph_init_date = INTEGER`.4.7https://git.dynare.org/Dynare/dynare/-/issues/1675Migrate to Dragonfly parallel toolkit2021-05-06T14:33:48ZSébastien VillemotMigrate to Dragonfly parallel toolkitThe embedded parallel toolkit should be replaced by the [Dragonfly](https://github.com/DragonflyTeam/dragonfly) toolkit.
A branch called `dragonfly` has been created, with the toolkit under `matlab/modules/dragonfly` (see ee3971ad6364910851ff06da9729d9b4a084ca4b).The embedded parallel toolkit should be replaced by the [Dragonfly](https://github.com/DragonflyTeam/dragonfly) toolkit.
A branch called `dragonfly` has been created, with the toolkit under `matlab/modules/dragonfly` (see ee3971ad6364910851ff06da9729d9b4a084ca4b).4.8Marco RattoMarco Rattohttps://git.dynare.org/Dynare/dynare/-/issues/1680Adapt evaluate_planner_objective.m to higher order and perfect foresight2021-02-26T11:43:12ZJohannes Pfeifer Adapt evaluate_planner_objective.m to higher order and perfect foresightSupersedes https://git.dynare.org/Dynare/dynare/issues/564 and is related to https://git.dynare.org/Dynare/dynare/issues/1678
See also https://forum.dynare.org/t/evaluate-planner-objective-in-non-linear-model/15492Supersedes https://git.dynare.org/Dynare/dynare/issues/564 and is related to https://git.dynare.org/Dynare/dynare/issues/1678
See also https://forum.dynare.org/t/evaluate-planner-objective-in-non-linear-model/154924.7Normann RionNormann Rionhttps://git.dynare.org/Dynare/dynare/-/issues/1684New WITH_TREND() operator for epilogue block2019-12-13T17:29:05ZSébastien VillemotNew WITH_TREND() operator for epilogue blockImplement a new operator (something like `WITH_TREND()` that could be used in the epilogue block, and that would add back the trend on the computed variables. In this way, the symbolic manipulations would be done in the preprocessor, which is much more easier to do than in MATLAB.
Initially discussed in #1648Implement a new operator (something like `WITH_TREND()` that could be used in the epilogue block, and that would add back the trend on the computed variables. In this way, the symbolic manipulations would be done in the preprocessor, which is much more easier to do than in MATLAB.
Initially discussed in #16484.7https://git.dynare.org/Dynare/dynare/-/issues/1688fix `basic_plan`, `flip_plan` in doc2020-01-28T14:01:41ZHoutan Bastanifix `basic_plan`, `flip_plan` in docThe calling structure for both of these functions runs off the end of the pageThe calling structure for both of these functions runs off the end of the page4.7Stéphane Adjemianstepan@adjemian.euStéphane Adjemianstepan@adjemian.euhttps://git.dynare.org/Dynare/dynare/-/issues/1693Various improvements in Sphinx doc2020-01-08T16:24:40ZHoutan BastaniVarious improvements in Sphinx doc- see if we can use https://pypi.org/project/sphinxcontrib-matlabdomain/ instead of `MatComm` and `MatlabVar` defined in `doc/manual/utils/dynare_dom.py`
- if not, add new domain entry to differentiate between MATLAB commands and MATLAB functions
- find way to fix output of Matlab Commands so the options conform to the true type used for Dynare Command options
- code block:
- many general problems with highlighting: e.g. `end` is highlighted when it is MATLAB code but the corresponding `for` is not highlighted
- despite being in `doc/manual/utils/dynare_lex.py`, `var` is not highlighted in code blocks
- ideally find a programmatic way to fill `doc/manual/utils/dynare_lex.py` from the `rst` files instead of having to update it by hand- see if we can use https://pypi.org/project/sphinxcontrib-matlabdomain/ instead of `MatComm` and `MatlabVar` defined in `doc/manual/utils/dynare_dom.py`
- if not, add new domain entry to differentiate between MATLAB commands and MATLAB functions
- find way to fix output of Matlab Commands so the options conform to the true type used for Dynare Command options
- code block:
- many general problems with highlighting: e.g. `end` is highlighted when it is MATLAB code but the corresponding `for` is not highlighted
- despite being in `doc/manual/utils/dynare_lex.py`, `var` is not highlighted in code blocks
- ideally find a programmatic way to fill `doc/manual/utils/dynare_lex.py` from the `rst` files instead of having to update it by hand4.7https://git.dynare.org/Dynare/dynare/-/issues/1698Allow checking linearity for perfect foresight models2020-02-14T15:05:47ZJohannes Pfeifer Allow checking linearity for perfect foresight modelsThe linearity check underlying `model(linear)` is based on the Hessian of the model. But we don’t compute the Hessian for a perfect foresight simulation, hence the check is skipped. See line 799 of `preprocessor/src/ModFile.cc`.
That can be problematic in case of nonlinearities like a ZLB constraint in an otherwise linear model. The solver assumes that the Jacobian is the same at every period, and the constraint is not enforced.
For very large perfect foresight models, we actually don’t want to put the Hessian in the generated dynamic file, because compiling it can be very time consuming. Hence the fix is not straightforward.
I would suggest to add a way of testing this. One option would be trigger the Hessian computation with a `debug` option or something like this. For example, we could use the already present command line option `debug`.The linearity check underlying `model(linear)` is based on the Hessian of the model. But we don’t compute the Hessian for a perfect foresight simulation, hence the check is skipped. See line 799 of `preprocessor/src/ModFile.cc`.
That can be problematic in case of nonlinearities like a ZLB constraint in an otherwise linear model. The solver assumes that the Jacobian is the same at every period, and the constraint is not enforced.
For very large perfect foresight models, we actually don’t want to put the Hessian in the generated dynamic file, because compiling it can be very time consuming. Hence the fix is not straightforward.
I would suggest to add a way of testing this. One option would be trigger the Hessian computation with a `debug` option or something like this. For example, we could use the already present command line option `debug`.4.7https://git.dynare.org/Dynare/dynare/-/issues/1700Proposal for a generalized solver2020-01-30T09:53:09ZMichelJuillardProposal for a generalized solverModel inversion and deterministic conditional forecast solve the same mathematical problem: solving a (non-)linear system where the identity of the unknown variables change from period to period. I suggest to create a unique function that would solve such problems.
``general_solver`` would take at least the following arguments:
* y: endogenous variables (matrix)
* x: exogenous variables (matrix) [possible concatenation of exo_det variables to the right]
* model: model (function handle)
* i_endo_flip: flip variables indices in endogenous variables (vector)
* i_exo_flip: flip variables indices in exogenous variables (vector)
### Conventions
1. there are as many endogenous flip variables as exogenenous or exo det variables
1. the endogenous and exogenous flip variables are in the same order (not necessary to be contiguous but may help)
1. given the indices vector of flip variablesm implicit pairs of endogenous/exogenous variables are formed
1. If the observation of an endogenous variable is a NaN, the endogenous variables plays it usual role of endogenous variable
1. If the observation of an endogenous variables is a valid number, the endogenous variable is treated as exogenous and the corresponding flip exogenous variables is treated as endogenous
1. The presence of a NaN for an endogenous variable not declared as a flip variable is an error
1. The corner case of unconditional forecast should be accepted for ease of use
1. The solution is written back in ``y`` and ``x`` irrespective of the actual role of a variable in a given period
### Operations
``general_solver`` dispatches la résolution du nouveau problème selon
1. purely backward linear model
1. purely backward nonlinear model
1. purely forward linear model (if we have the algorithm...)
1. purely forward nonlinear model
1. general linear model
1. general nonlinear model
1. bytecode and or block model
and according to the options selecting a particular algorithmModel inversion and deterministic conditional forecast solve the same mathematical problem: solving a (non-)linear system where the identity of the unknown variables change from period to period. I suggest to create a unique function that would solve such problems.
``general_solver`` would take at least the following arguments:
* y: endogenous variables (matrix)
* x: exogenous variables (matrix) [possible concatenation of exo_det variables to the right]
* model: model (function handle)
* i_endo_flip: flip variables indices in endogenous variables (vector)
* i_exo_flip: flip variables indices in exogenous variables (vector)
### Conventions
1. there are as many endogenous flip variables as exogenenous or exo det variables
1. the endogenous and exogenous flip variables are in the same order (not necessary to be contiguous but may help)
1. given the indices vector of flip variablesm implicit pairs of endogenous/exogenous variables are formed
1. If the observation of an endogenous variable is a NaN, the endogenous variables plays it usual role of endogenous variable
1. If the observation of an endogenous variables is a valid number, the endogenous variable is treated as exogenous and the corresponding flip exogenous variables is treated as endogenous
1. The presence of a NaN for an endogenous variable not declared as a flip variable is an error
1. The corner case of unconditional forecast should be accepted for ease of use
1. The solution is written back in ``y`` and ``x`` irrespective of the actual role of a variable in a given period
### Operations
``general_solver`` dispatches la résolution du nouveau problème selon
1. purely backward linear model
1. purely backward nonlinear model
1. purely forward linear model (if we have the algorithm...)
1. purely forward nonlinear model
1. general linear model
1. general nonlinear model
1. bytecode and or block model
and according to the options selecting a particular algorithm4.7https://git.dynare.org/Dynare/dynare/-/issues/1703det_cond_forecast() depends on oo_.dr.state_var but this is not always available2021-02-18T15:42:50ZMichelJuillarddet_cond_forecast() depends on oo_.dr.state_var but this is not always available``det_cond_forecast()`` depends on ``oo_.dr.state_var`` but this variable is computed by ``dyn_first_order_solver``. So it isn't available for a purely backward or purely forward model``det_cond_forecast()`` depends on ``oo_.dr.state_var`` but this variable is computed by ``dyn_first_order_solver``. So it isn't available for a purely backward or purely forward model4.7MichelJuillardMichelJuillardhttps://git.dynare.org/Dynare/dynare/-/issues/1704Update partial information code2021-05-03T13:59:02ZSébastien VillemotUpdate partial information codeFirst version located in https://git.dynare.org/Yang/dynareFirst version located in https://git.dynare.org/Yang/dynare4.8https://git.dynare.org/Dynare/dynare/-/issues/1707Macro commands that take no arguments have spurious parentheses appended to t...2020-05-07T17:43:51ZSébastien VillemotMacro commands that take no arguments have spurious parentheses appended to their synopsisSee for example the definition of `@#else`, `@#endif`, `@#endfor`, `@#echomacrovars` in the reference manual.See for example the definition of `@#else`, `@#endif`, `@#endfor`, `@#echomacrovars` in the reference manual.4.7https://git.dynare.org/Dynare/dynare/-/issues/1709Automatic detrending2020-03-06T17:35:41ZFerhatMihoubiAutomatic detrendingFor the moment the deterministic or stochastic trends have to be declared using the trend_var (or log_trend_var) commands and the option deflator (or log_deflator) in var command to declare the trended variables.
The purpose of the new feature is to find and remove automatically the trends. To do so, the proposal is to add :
- an option in var command to indicate if the variable is expressed in logarithm or not (the default being not in logarithm). For instance *var(log) list of variables*.
- a command that will add to all endogenous variables a growth factor (additive or multiplicative depending on the previously declared status) and the equations that put in relation all the growth factors to theirs endogenous variables. This step should be performed in the preprocessor to produce a new dynamic model containing all the endogenous variables and the growth factor associated to all the endogenous variables.
- during the execution the complete new dynamic model should be solved to compute the growth factors and the steady state values of the endogenous variables.
This command could be *detrend* for instance.For the moment the deterministic or stochastic trends have to be declared using the trend_var (or log_trend_var) commands and the option deflator (or log_deflator) in var command to declare the trended variables.
The purpose of the new feature is to find and remove automatically the trends. To do so, the proposal is to add :
- an option in var command to indicate if the variable is expressed in logarithm or not (the default being not in logarithm). For instance *var(log) list of variables*.
- a command that will add to all endogenous variables a growth factor (additive or multiplicative depending on the previously declared status) and the equations that put in relation all the growth factors to theirs endogenous variables. This step should be performed in the preprocessor to produce a new dynamic model containing all the endogenous variables and the growth factor associated to all the endogenous variables.
- during the execution the complete new dynamic model should be solved to compute the growth factors and the steady state values of the endogenous variables.
This command could be *detrend* for instance.https://git.dynare.org/Dynare/dynare/-/issues/1715Clean root folder of /tests2021-01-22T13:29:50ZJohannes Pfeifer Clean root folder of /testsAll integration tests should be in subfolders. The current structure is a messAll integration tests should be in subfolders. The current structure is a mess4.7https://git.dynare.org/Dynare/dynare/-/issues/1716Fix bug in contemp_reduced_form of SBVAR2020-03-16T08:27:57ZJohannes Pfeifer Fix bug in contemp_reduced_form of SBVARAs outlined in https://forum.dynare.org/t/different-results-of-a0-using-sbvar/15359 the attached codes crashes due to non-conformable matrices.
[MacroData.mat](/uploads/e30cd873d1add8fc54a1e0e65aa0949d/MacroData.mat)
[constantRecursiveBVAR.mod](/uploads/f7b1c204676a2323d03a467702f6e3c5/constantRecursiveBVAR.mod)As outlined in https://forum.dynare.org/t/different-results-of-a0-using-sbvar/15359 the attached codes crashes due to non-conformable matrices.
[MacroData.mat](/uploads/e30cd873d1add8fc54a1e0e65aa0949d/MacroData.mat)
[constantRecursiveBVAR.mod](/uploads/f7b1c204676a2323d03a467702f6e3c5/constantRecursiveBVAR.mod)https://git.dynare.org/Dynare/dynare/-/issues/1721Get rid of oo_.dr.kstate2020-05-04T16:22:55ZSébastien VillemotGet rid of oo_.dr.kstateIn particular, see the discussion in #1653In particular, see the discussion in #16534.7https://git.dynare.org/Dynare/dynare/-/issues/1734Finish nonlinear prior restrictions2020-06-22T10:25:28ZJohannes Pfeifer Finish nonlinear prior restrictionsSee https://git.dynare.org/Dynare/dynare/-/commit/0efcef8f20c549c1484ce56c8986bc4c24d5292aSee https://git.dynare.org/Dynare/dynare/-/commit/0efcef8f20c549c1484ce56c8986bc4c24d5292a4.7https://git.dynare.org/Dynare/dynare/-/issues/1738Publication-quality plots2020-07-15T10:44:06ZWilli Mutschlerwilli@mutschler.euPublication-quality plotsMatlab's capabilities to produce plots are very low-level and I usually find that using e.g. R's ggplot2 function gives "better" looking figures. I recently came across the following project which basically ports ggplot2 to matlab and is under the MIT license:
https://github.com/piermorel/gramm
What do @all think, would it be good to use this and provide publication-quality plots in Dynare?Matlab's capabilities to produce plots are very low-level and I usually find that using e.g. R's ggplot2 function gives "better" looking figures. I recently came across the following project which basically ports ggplot2 to matlab and is under the MIT license:
https://github.com/piermorel/gramm
What do @all think, would it be good to use this and provide publication-quality plots in Dynare?