dynare issueshttps://git.dynare.org/Dynare/dynare/-/issues2018-09-10T12:35:46Zhttps://git.dynare.org/Dynare/dynare/-/issues/1605Better document behavior of steady_state operator2018-09-10T12:35:46ZJohannes Pfeifer Better document behavior of steady_state operatorSee https://forum.dynare.org/t/steady-state-command-in-perfect-foresight-simulations/11632/3See https://forum.dynare.org/t/steady-state-command-in-perfect-foresight-simulations/11632/3https://git.dynare.org/Dynare/dynare/-/issues/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/1282MS-SBVAR: Potentially allow for linear restrictions across A0 and Aplus2018-09-11T15:00:44ZJohannes Pfeifer MS-SBVAR: Potentially allow for linear restrictions across A0 and AplusAfter a user inquiry at http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=9594, @dwaggoner replied with the following. The question is now whether we want to implement this?
The underlying C code can handle linear restrictions across `A0` and `Aplus` as long as they are not cross-equation. Also the restrictions must be linear, not affine, i.e. no non-zero constant. It seems like this is what the person is asking for. Also, this cannot be used with the Sims-Zha specification as that requires `Aplus` to be unrestricted.
Each column (equation) of `A0` and Aplus can be restricted to be of the form
```
a_j = U[j]*b_j
aplus_j = V[j]*g_j + W[j]*a_j
```
Here `b_j` and `g_j` are the "free parameters", with `a_j` and `aplus_j` are the columns of `A0` and `Aplus`. The cross `A0` - `Aplus` restrictions require `W[j]` to be non-zero.
The work will be going from the dynare file to producing `U[j]`, `V[j]`, and `W[j]`. You already produce `U[j]` and `V[j]`, so producing `W[j]` should not be to much more work.
After a user inquiry at http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=9594, @dwaggoner replied with the following. The question is now whether we want to implement this?
The underlying C code can handle linear restrictions across `A0` and `Aplus` as long as they are not cross-equation. Also the restrictions must be linear, not affine, i.e. no non-zero constant. It seems like this is what the person is asking for. Also, this cannot be used with the Sims-Zha specification as that requires `Aplus` to be unrestricted.
Each column (equation) of `A0` and Aplus can be restricted to be of the form
```
a_j = U[j]*b_j
aplus_j = V[j]*g_j + W[j]*a_j
```
Here `b_j` and `g_j` are the "free parameters", with `a_j` and `aplus_j` are the columns of `A0` and `Aplus`. The cross `A0` - `Aplus` restrictions require `W[j]` to be non-zero.
The work will be going from the dynare file to producing `U[j]`, `V[j]`, and `W[j]`. You already produce `U[j]` and `V[j]`, so producing `W[j]` should not be to much more work.
https://git.dynare.org/Dynare/dynare/-/issues/1055Deprecate first_obs and last_obs in data command2018-09-11T15:00:44ZStéphane Adjemianstepan@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/1044Clear up option mh_posterior_mode_estimation2018-09-11T15:00:44ZJohannes Pfeifer Clear up option mh_posterior_mode_estimationSee the question at http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=7235
Does anyone know what it does?
Looking at the codes in `dynare_estimation_1.m` this option seems to skip mode computation and directly runs the MCMC, using the prior mode as the starting point and the prior variances for computing the inverse Hessian for the MCMC. In case of the mode not existing, the prior mean is used.
But already before doing so, it sets
```
oo_.posterior.optimization.mode = xparam1;
oo_.posterior.optimization.Variance = [];
```
That is, the mode saved is based on the starting values given for MCMC and no variance is saved. This looks like a a bug as the MCMC starts with values that are only set after this assignment.
Finally, this option runs the MCMC and calls `CutSample.m` before returning. What is the point of just estimating the MCMC starting at the prior mode and providing no output?
We should either document the option and add a preprocessor command or get rid of it.
See the question at http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=7235
Does anyone know what it does?
Looking at the codes in `dynare_estimation_1.m` this option seems to skip mode computation and directly runs the MCMC, using the prior mode as the starting point and the prior variances for computing the inverse Hessian for the MCMC. In case of the mode not existing, the prior mean is used.
But already before doing so, it sets
```
oo_.posterior.optimization.mode = xparam1;
oo_.posterior.optimization.Variance = [];
```
That is, the mode saved is based on the starting values given for MCMC and no variance is saved. This looks like a a bug as the MCMC starts with values that are only set after this assignment.
Finally, this option runs the MCMC and calls `CutSample.m` before returning. What is the point of just estimating the MCMC starting at the prior mode and providing no output?
We should either document the option and add a preprocessor command or get rid of it.
https://git.dynare.org/Dynare/dynare/-/issues/819Support DSGE-VAR forecasts2018-09-11T15:00:44ZJohannes Pfeifer Support DSGE-VAR forecastsCurrently, forecasts are based on the DSGE model and not the DSGE-VAR
Currently, forecasts are based on the DSGE model and not the DSGE-VAR
https://git.dynare.org/Dynare/dynare/-/issues/1503Do we really need to have specific dynamic routines for deterministic and sto...2018-09-11T15:00:44ZStéphane Adjemianstepan@adjemian.euDo we really need to have specific dynamic routines for deterministic and stochastic models?See discussion in #1501.See discussion in #1501.https://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/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/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/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/1438Write a unit test for mjdgges (m implementation)2018-09-11T15:00:44ZStéphane Adjemianstepan@adjemian.euWrite a unit test for mjdgges (m implementation)Based on matrices E and D from the example contributed by @JohannesPfeifer in #1154.Based on matrices E and D from the example contributed by @JohannesPfeifer in #1154.Stéphane Adjemianstepan@adjemian.euStéphane Adjemianstepan@adjemian.euhttps://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/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/1576Provide steady state file example for Ramsey2018-11-08T10:12:38ZJohannes Pfeifer Provide steady state file example for RamseyThe final loop should most probably be
```
NumberOfEndogenousVariables = M_.endo_nbr; % Number of endogenous variables.
ys = zeros(NumberOfEndogenousVariables,1); % Initialization of ys (steady state).
for i = M_.ramsey_eq_nbr+1:NumberOfEndogenousVariables % Loop...
varname = deblank(M_.endo_names(i-M_.ramsey_eq_nbr,:)); % Get the name of endogenous variable i.
eval(['ys(' int2str(i) ') = ' varname ';']); % Get the steady state value of this variable.
end % End of the loop.
```The final loop should most probably be
```
NumberOfEndogenousVariables = M_.endo_nbr; % Number of endogenous variables.
ys = zeros(NumberOfEndogenousVariables,1); % Initialization of ys (steady state).
for i = M_.ramsey_eq_nbr+1:NumberOfEndogenousVariables % Loop...
varname = deblank(M_.endo_names(i-M_.ramsey_eq_nbr,:)); % Get the name of endogenous variable i.
eval(['ys(' int2str(i) ') = ' varname ';']); % Get the steady state value of this variable.
end % End of the loop.
```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/1573Allow mode_compute to be a vector2018-11-08T10:14:12ZJohannes 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/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/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.eu