Dynare issueshttps://git.dynare.org/groups/Dynare/-/issues2018-09-11T15:00:44Zhttps://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 sho...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/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/846Provide inverse gamma prior with indeterminate moments2023-10-02T15:44:53ZJohannes PfeiferProvide 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.o...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 #520https://git.dynare.org/Dynare/dynare/-/issues/835Behavior of STEADY_STATE() in perfect foresight models with anticipated perma...2023-10-02T15:45:03ZSté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 sh...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/832Use dseries objects in Dynare2023-06-13T13:21: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 D...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/829Rewrite local_state_space_iteration_2 routine2021-08-15T19:40:51ZSté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, particularly https://git.dynare.org/Dynare/particles/-/issues/2Separate the measurement and state equations. See discussions in [particles](https://git.dynare.org/Dynare/particles/-/issues) repository, particularly https://git.dynare.org/Dynare/particles/-/issues/2Stéphane Adjemianstepan@adjemian.euStéphane Adjemianstepan@adjemian.euhttps://git.dynare.org/Dynare/dynare/-/issues/827Feature request: Implement the algorithm of Ajevskis (2014) for perturbation ...2022-06-01T13:24:06ZTom 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 ...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.htmlhttps://git.dynare.org/Dynare/dynare/-/issues/824Add an interface for joint priors.2021-09-01T14:06:52ZSté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/819Support DSGE-VAR forecasts2018-09-11T15:00:44ZJohannes PfeiferSupport 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/m-unit-tests/-/issues/1Add missing isoctave routine2018-10-25T02:31:35ZStéphane Adjemianstepan@adjemian.euAdd missing isoctave routineThis routine is distributed with dynare. If `m-unit-tests` routines are not used as a submodule of dynare or if dynare/matlab directory is not in the path, unit tests will fail because of the absence of the routine `isoctave`.
This routine is distributed with dynare. If `m-unit-tests` routines are not used as a submodule of dynare or if dynare/matlab directory is not in the path, unit tests will fail because of the absence of the routine `isoctave`.
https://git.dynare.org/Dynare/dynare/-/issues/709Preprocessor: Allow reusage of model local variable names in steady_state_mod...2023-10-02T15:42:48ZTom 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 variabl...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/642Support Dirichlet prior distribution2021-09-03T12:01:06ZHoutan 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/preprocessor/-/issues/78Improving Ramsey computations: allow estimating discount factor2023-10-02T15:43:30ZMichelJuillardImproving Ramsey computations: allow estimating discount factorAdd the possibility to use one of the parameters of the model as the planner_discount factorAdd the possibility to use one of the parameters of the model as the planner_discount factorhttps://git.dynare.org/Dynare/dynare/-/issues/614Have balanced growth test consider steady_state_model-block2022-12-09T13:31:48ZMichelJuillardHave balanced growth test consider steady_state_model-blockHere 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 ...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);
```https://git.dynare.org/Dynare/dynare/-/issues/530checking singularity in first order approximation2021-08-15T19:44:22ZMichelJuillardchecking 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 ramse...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 PfeiferSupport 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/416Document how to do learning with Dynare2019-11-21T08:36:42ZJohannes PfeiferDocument 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/326Change color scheme of figures to be readable on monochrome printouts2019-06-19T15:37:41ZJohannes PfeiferChange 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/300Implement k-order derivatives of external functions2023-02-24T21:55:57ZSébastien VillemotImplement k-order derivatives of external functionsOtherwise order ≥ 3 fails with a cryptic preprocessor errorOtherwise order ≥ 3 fails with a cryptic preprocessor errorhttps://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 ...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.