dynare issueshttps://git.dynare.org/Dynare/dynare/-/issues2021-09-22T15:30:36Zhttps://git.dynare.org/Dynare/dynare/-/issues/1044Clear up option mh_posterior_mode_estimation2021-09-22T15:30:36ZJohannes 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 pr...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.4.7https://git.dynare.org/Dynare/dynare/-/issues/713Block recursive prior definitions2021-09-21T15:21:04ZJohannes 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 parame...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?4.7https://git.dynare.org/Dynare/dynare/-/issues/1786Check iterative OLS and NLS estimation approaches for the estimation of the P...2021-09-13T08:46:33ZStéphane Adjemianstepan@adjemian.euCheck iterative OLS and NLS estimation approaches for the estimation of the PAC equationThe sum of square residuals should always be smaller (provided that the optimization algorithm does not fail or reach a local minimum) with NLS. Conduct a Monte-Carlo exercise to check that this is what we observe.The sum of square residuals should always be smaller (provided that the optimization algorithm does not fail or reach a local minimum) with NLS. Conduct a Monte-Carlo exercise to check that this is what we observe.Stéphane Adjemianstepan@adjemian.euStéphane Adjemianstepan@adjemian.euhttps://git.dynare.org/Dynare/dynare/-/issues/1734Finish nonlinear prior restrictions2021-08-17T19:04:34ZJohannes 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/444Document remaining options of nonlinear filters2021-08-17T10:25:22ZStéphane Adjemianstepan@adjemian.euDocument remaining options of nonlinear filtersWe need to describe and discuss all the available options in `options_.particle`. Setting options has been introduced in https://git.dynare.org/Dynare/dynare/-/merge_requests/1884. Still to do
- [x] Adjust the wiki to reflect the new way...We need to describe and discuss all the available options in `options_.particle`. Setting options has been introduced in https://git.dynare.org/Dynare/dynare/-/merge_requests/1884. Still to do
- [x] Adjust the wiki to reflect the new way of setting these options
- [x] Add information to the manual (a link to the wiki is the minimum)4.7Johannes Pfeifer Johannes Pfeifer https://git.dynare.org/Dynare/dynare/-/issues/339Clarify difference between Bayesian HPDI and classical confidence bands in ma...2021-08-17T10:24:01ZJohannes 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/312Allow User to choose Mean or Median statistics2021-08-15T19:47:20ZJohannes 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 p...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/520Weibull prior distibution2021-08-02T11:31:20ZMichelJuillardWeibull prior distibutionCMR 2013 are using a Weibull prior distribution. I suggest to add it to the list of prior used by Dynare
CMR 2013 are using a Weibull prior distribution. I suggest to add it to the list of prior used by Dynare
4.5Johannes Pfeifer Johannes Pfeifer https://git.dynare.org/Dynare/dynare/-/issues/750Decide on treatment of prior truncation during estimation2021-08-02T11:28:56ZJohannes Pfeifer Decide on treatment of prior truncation during estimationWe need to decide on how to proceed, see https://github.com/DynareTeam/dynare/commit/aa503abfa79145efc0840c79210e795e1b76df84
We need to decide on how to proceed, see https://github.com/DynareTeam/dynare/commit/aa503abfa79145efc0840c79210e795e1b76df84
4.5Stéphane Adjemianstepan@adjemian.euStéphane Adjemianstepan@adjemian.euhttps://git.dynare.org/Dynare/dynare/-/issues/1769Discuss merging dsge_simulated_theoretical_correlation and dsge_simulated_the...2021-07-22T16:25:02ZJohannes Pfeifer Discuss merging dsge_simulated_theoretical_correlation and dsge_simulated_theoretical_covariance`dsge_simulated_theoretical_covariance` sets `options_.ar = 0` before calling `th_autocovariances`. `dsge_simulated_theoretical_correlation` again calls `th_autocovariances` and therefore recomputes the variance. One call with `options_....`dsge_simulated_theoretical_covariance` sets `options_.ar = 0` before calling `th_autocovariances`. `dsge_simulated_theoretical_correlation` again calls `th_autocovariances` and therefore recomputes the variance. One call with `options_.nar` would suffice. This inefficiency is even more pronounced at higher order with `pruning` where we need to call `pruned_state_space_system`.
We should either
1. Merge the two functions.
2. Have `dsge_simulated_theoretical_covariance` compute and store everything and only use `dsge_simulated_theoretical_correlation` to fill the fields.4.7https://git.dynare.org/Dynare/dynare/-/issues/1173Support estimation under optimal policy2021-07-22T13:33:48ZJohannes Pfeifer Support estimation under optimal policySee http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=8071See http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=80714.7Sébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/1783bug with auxiliary exo lags with loglinear2021-05-11T16:52:22ZMarco Rattobug with auxiliary exo lags with loglinearIn the new unit test `fs2000_het.mod`, (merge request !1844), I added a shock to the model to test `heteroskedastic_shocks`. doing that I noted a bug at the interaction between loglinear and auxiliary exo lag variables.
It turns out that...In the new unit test `fs2000_het.mod`, (merge request !1844), I added a shock to the model to test `heteroskedastic_shocks`. doing that I noted a bug at the interaction between loglinear and auxiliary exo lag variables.
It turns out that this modified mod file triggers an auxiliary lagged exo variable.
for this variable, ys is set to zero, which is then logged in `store_smoother_results`, resulting in inf's for that variable in `oo_.SmoothedVariables` etc.
Moreover, running forecast after that, this triggers nan for all forecasted variables.4.7https://git.dynare.org/Dynare/dynare/-/issues/1761Method of Moments mode_compute 11 and 122021-01-13T14:59:36ZWilli Mutschlerwilli@mutschler.euMethod of Moments mode_compute 11 and 12In merge request !1799 I added a test mod file RBC_MoM_optimizer.mod which runs through all optimizers to check whether the call to the optimizers succeeds. For mode_compute=11 and mode_compute=12, at least for me, there is an error.In merge request !1799 I added a test mod file RBC_MoM_optimizer.mod which runs through all optimizers to check whether the call to the optimizers succeeds. For mode_compute=11 and mode_compute=12, at least for me, there is an error.4.7Willi Mutschlerwilli@mutschler.euWilli Mutschlerwilli@mutschler.euhttps://git.dynare.org/Dynare/dynare/-/issues/1204Crash in unstable mex when called from parallel workers2020-11-13T13:44:38ZTom 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) ...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.Stéphane Adjemianstepan@adjemian.euStéphane Adjemianstepan@adjemian.euhttps://git.dynare.org/Dynare/dynare/-/issues/1718Auxillary particle filter --- number_of_state_variables is undefined2020-11-13T12:19:37ZArtur ZmanovskiiAuxillary particle filter --- number_of_state_variables is undefinedIn `particles/src/auxiliary_particle_filter.m` under specific options (`options_.particle.pruning=1`, `resampling` in `estimation()` is `systematic/generic`), a chunk of code is executed (lines 136--139), which has undefined variable (`n...In `particles/src/auxiliary_particle_filter.m` under specific options (`options_.particle.pruning=1`, `resampling` in `estimation()` is `systematic/generic`), a chunk of code is executed (lines 136--139), which has undefined variable (`number_of_state_variables` --- at lines 137--138) and causes error.4.7Stéphane Adjemianstepan@adjemian.euStéphane Adjemianstepan@adjemian.euhttps://git.dynare.org/Dynare/dynare/-/issues/1724Discuss interface for method of Moments in Dynare (GMM, SMM, IRF Matching)2020-08-05T14:38:34ZWilli Mutschlerwilli@mutschler.euDiscuss interface for method of Moments in Dynare (GMM, SMM, IRF Matching)Hey,
I am working on a first draft for a toolbox for moment estimation with GMM, SMM and IRF-Matching (I will start with GMM, then SMM, and deal with IRF-matching later) which will work for perturbation (with pruning) up to third-order. ...Hey,
I am working on a first draft for a toolbox for moment estimation with GMM, SMM and IRF-Matching (I will start with GMM, then SMM, and deal with IRF-matching later) which will work for perturbation (with pruning) up to third-order. I have a couple of questions|proposal for the best interface and call for this and would like your guys take on this.
### Declaring parameters
Here I would simply opt to what we do in a Maximum likelihood estimation and use the same syntax in an `estimated_params` or an `estimated_params_bounds` block:
```
stderr VARIABLE_NAME | corr VARIABLE_NAME_1, VARIABLE_NAME_2 | PARAMETER_NAME, LOWER_BOUND, UPPER_BOUND;
```
### Declaring which moments to use
Here I would propose a block similar to `moment_calibration`, but call it `estimated_moments`:
```
estimated_moments;
y_obs,y_obs; //[unconditional variance]
y_obs,y_obs(-(1:4)); //[some acf]
@#for ilag in -2:2
y_obs,R_obs(@{ilag}); //[ccf]
@#endfor
end;
```
### Invocation
Now the toughest question. How to invoke it? I see two options.
Option A: Add an option to `estimation`, e.g.
```
estimation(moments_estimation='GMM');
```
Option B: Have an own command for this, e.g.:
```
gmm_estimation(OPTIONS);
smm_estimation(OPTIONS);
irf_matching(OPTIONS);
```
which then internally calls a wrapper `dynare_moments_estimation.m` and runs the toolbox.
What do you guys think?4.7https://git.dynare.org/Dynare/dynare/-/issues/251SMM: create preprocessor interface, make it compatible with Octave2020-05-28T08:57:07ZSébastien VillemotSMM: create preprocessor interface, make it compatible with OctaveIn particular, the current code is not compatible with Octave since it uses RandStream at several places.
In particular, the current code is not compatible with Octave since it uses RandStream at several places.
https://git.dynare.org/Dynare/dynare/-/issues/1673Nonlinear filters at k-order2020-02-17T09:28:31ZSébastien VillemotNonlinear filters at k-orderA MEX file for iterating in the state space (based on Dynare++) is already present in the `local_state_space_iteration_k` branch.
It needs to be tested and integrated in the estimation routines.A MEX file for iterating in the state space (based on Dynare++) is already present in the `local_state_space_iteration_k` branch.
It needs to be tested and integrated in the estimation routines.4.6Stéphane Adjemianstepan@adjemian.euStéphane Adjemianstepan@adjemian.euhttps://git.dynare.org/Dynare/dynare/-/issues/1659Filter out non-positive definite Hessians before Laplace approximation2019-11-21T14:06:17ZJohannes Pfeifer Filter out non-positive definite Hessians before Laplace approximationWe do not check whether the normal approximation underlying the Laplace approximation to the marginal data density makes any sense given the Hessian at hand. That results in wrong output, because the log determinant will be complex and M...We do not check whether the normal approximation underlying the Laplace approximation to the marginal data density makes any sense given the Hessian at hand. That results in wrong output, because the log determinant will be complex and Matlab only prints the real-valued parts.
See https://forum.dynare.org/t/hessian-matrix-at-the-mode-is-not-positive-definite-but-the-marginal-density-is-displayed-anyway/14510/3
Proposed solution: skip the computation of the Hessian is not positive semi-definite and return NaN.4.6Johannes Pfeifer Johannes Pfeifer https://git.dynare.org/Dynare/dynare/-/issues/644support mcmc_* options wherever there's an mh_* option2019-11-21T08:36:45ZHoutan Bastanisupport mcmc_* options wherever there's an mh_* optionas mcmc is more general than mh. support mh_\* for backwards compatibility.
as mcmc is more general than mh. support mh_\* for backwards compatibility.