dynare issueshttps://git.dynare.org/Dynare/dynare/-/issues2019-06-19T15:37:56Zhttps://git.dynare.org/Dynare/dynare/-/issues/1012Add one-sided HP filter2019-06-19T15:37:56ZJohannes PfeiferAdd one-sided HP filter#1011 already implemented the interface. Before adding the function, we need to decide whether to simply add it as a function that operates on regular double data like the `sample_hp_filter` or whether we want to make it a function on ds...#1011 already implemented the interface. Before adding the function, we need to decide whether to simply add it as a function that operates on regular double data like the `sample_hp_filter` or whether we want to make it a function on dseries objects as the `baxter_king_filter.m` of the dseries submodule.
https://git.dynare.org/Dynare/dynare/-/issues/814Decide upon what to do stale mode_compute options2019-06-19T15:38:02ZJohannes PfeiferDecide upon what to do stale mode_compute optionsIn the process of factorizing the optimization calls (see #800), we should clean up. Currently, `mode_compute==2,101,102` are broken/not supported anymore. 2 and 102 are non-existing simulated annealings. I would propose to drop 102 and ...In the process of factorizing the optimization calls (see #800), we should clean up. Currently, `mode_compute==2,101,102` are broken/not supported anymore. 2 and 102 are non-existing simulated annealings. I would propose to drop 102 and replace 2 by Matlab's
`simulannealbnd` from the Global Optimization Toolbox. That way we would have at least one simulated annealing available.
I have no clue why we have the undocumented 101 which is `solveopt` and would suggest to drop it.
https://git.dynare.org/Dynare/dynare/-/issues/670Fix handling of prefiltering and trends in non_linear_dsge_likelihood2019-06-19T15:38:08ZJohannes PfeiferFix handling of prefiltering and trends in non_linear_dsge_likelihood`non_linear_dsge_likelihood` uses
`Y = transpose(DynareDataset.rawdata);`
By accessing `rawdata` instead of data, prefiltering is ignored. Moreover, deterministic trends are not subtracted. I am not sure this is on purpose.
`non_linear_dsge_likelihood` uses
`Y = transpose(DynareDataset.rawdata);`
By accessing `rawdata` instead of data, prefiltering is ignored. Moreover, deterministic trends are not subtracted. I am not sure this is on purpose.
4.5https://git.dynare.org/Dynare/dynare/-/issues/667rename hessian.m in dyn_hessian.m2019-06-19T15:38:08ZMichelJuillardrename hessian.m in dyn_hessian.mIn order to avoid name collision with other Matlab program/toolboxe
In order to avoid name collision with other Matlab program/toolboxe
4.5https://git.dynare.org/Dynare/dynare/-/issues/573Fix bug in interaction of diffuse filter and stoch_simul2019-06-19T15:38:12ZJohannes PfeiferFix bug in interaction of diffuse filter and stoch_simulSee http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=5248
See http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=5248
4.5MichelJuillardMichelJuillardhttps://git.dynare.org/Dynare/dynare/-/issues/534Discuss allowed use of endogenous variables outside of model-block2019-06-19T15:38:14ZJohannes PfeiferDiscuss allowed use of endogenous variables outside of model-blockConsider the mod-file
```
var y, c, k, a, h, b;
varexo e, u;
parameters beta, rho, alpha, delta, theta, psi, tau test;
alpha = 0.36;
rho = 0.95;
tau = 0.025;
beta = 0.99;
delta = 0.025;
psi = 0;
theta = 2.95;
phi = 0.1;
test...Consider the mod-file
```
var y, c, k, a, h, b;
varexo e, u;
parameters beta, rho, alpha, delta, theta, psi, tau test;
alpha = 0.36;
rho = 0.95;
tau = 0.025;
beta = 0.99;
delta = 0.025;
psi = 0;
theta = 2.95;
phi = 0.1;
test=y*beta;
model;
c*theta*h^(1+psi)=(1-alpha)*y;
k = beta*(((exp(b)*c)/(exp(b(+1))*c(+1)))
*(exp(b(+1))*alpha*y(+1)+(1-delta)*k));
y = exp(a)*(k(-1)^alpha)*(h^(1-alpha));
k = exp(b)*(y-c)+(1-delta)*k(-1);
a = rho*a(-1)+tau*b(-1) + e;
b = tau*a(-1)+rho*b(-1) + u;
end;
initval;
y = 1.08068253095672;
c = 0.80359242014163;
h = 0.29175631001732;
k = 11.08360443260358;
a = 0;
b = 0;
e = 0;
u = 0;
end;
shocks;
var e; stderr 0.009;
var u; stderr 0.009;
var e, u = phi*0.009*0.009;
end;
stoch_simul;
```
The definition
`test=y*beta;`
results in the preprocessor plugging in for the endogenous variable `y` with its yet uncomputed steady state, i.e. 0. Users thus can create a circular problem with the steady state of `y` depending on `test` with `test` depending on `y` - and would never notice the problem, because the definition does not result in an error. Would it be possible to block this behavior? If we want to allow users to access the steady state value of endogenous variables outside of the model-block, it should be through the `steady_state`operator.
Or do I miss something that makes this behavior desirable?
4.5https://git.dynare.org/Dynare/dynare/-/issues/525Check prior truncation2019-06-19T15:38:14ZJohannes PfeiferCheck prior truncationThere are two issues:
a) There are three cases where priors are/should be truncated in Dynare
1. If the user explicitly specifies this
2. If the prior for a correlation has mass outside [-1,1]
3. If prior for standard deviations has mas...There are two issues:
a) There are three cases where priors are/should be truncated in Dynare
1. If the user explicitly specifies this
2. If the prior for a correlation has mass outside [-1,1]
3. If prior for standard deviations has mass below 0.
#522 suggests to issue a warning in cases 2 and 3. However, the point where truncation is problematic is computing marginal data densities. I suggest to set a flag for all three cases and issue a warning in marginal_density if the prior was truncated.
b) I am not sure I understand the prior truncation in case 1 above. The manual says that the prior does not integrate to 1 anymore. This is fine. But in `set_prior.m` we have code like
```
k = find(bayestopt_.pshape == 4);
k1 = find(isnan(bayestopt_.p3(k)));
k2 = find(isnan(bayestopt_.p4(k)));
bayestopt_.p3(k(k1)) = zeros(length(k1),1);
bayestopt_.p4(k(k2)) = Inf(length(k2),1);
for i=1:length(k)
[bayestopt_.p6(k(i)),bayestopt_.p7(k(i))] = ...
inverse_gamma_specification(bayestopt_.p1(k(i))-bayestopt_.p3(k(i)),bayestopt_.p2(k(i)),1,0) ;
bayestopt_.p5(k(i)) = compute_prior_mode([ bayestopt_.p6(k(i)) , bayestopt_.p7(k(i)) , bayestopt_.p3(k(i)) ], 4) ;
end
```
The way I read this, the mean of the prior seems to take the truncation in p3 into account. Thus, instead of fixing the prior distribution according to mean and variance and then truncating it, it seems we are partially setting the mean of the truncated distribution. I am not sure this behavior is desired/expected by the user. We at least need to document what Dynare is doing here.
https://git.dynare.org/Dynare/dynare/-/issues/504Discuss and document the load_mh_file option2019-06-19T15:38:16ZJohannes PfeiferDiscuss and document the load_mh_file optionThe current behavior of the `load_mh_file`-option with it recomputing the mode, the Hessian, and the scale-factor by default seems counterintuitive. Given the fixed seed, one should get the same results, but there is the risk of them cha...The current behavior of the `load_mh_file`-option with it recomputing the mode, the Hessian, and the scale-factor by default seems counterintuitive. Given the fixed seed, one should get the same results, but there is the risk of them changing between the reloaded chain and the new elements to be added and thus having a chain with difffering proposal densities. We should at least document this behavior and potentially reload the mode-file by default. See also http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=5051
4.5https://git.dynare.org/Dynare/dynare/-/issues/406Agree on system for storing results and figures2020-12-19T09:24:12ZJohannes PfeiferAgree on system for storing results and figuresCurrently we don't have a consistent system for saving results and figures. The MS-BVAR code for example saves the computation matrices in folders like IRF, Forecast, and Variance_Decomposition. But the corresponding graphs are saved in ...Currently we don't have a consistent system for saving results and figures. The MS-BVAR code for example saves the computation matrices in folders like IRF, Forecast, and Variance_Decomposition. But the corresponding graphs are saved in correspondingly named subfolders of the Output-Folder. This creates a confusing double structure. I am pretty sure there was some method to this separation, but I am unable to see it.
This treatment for example is different from other parts of the code, where results are either directly stored to "Output" or special folders like "gsa" are created at the same level as the Output folder.
In the longrun, we might want to agree on a consistent system.
https://git.dynare.org/Dynare/dynare/-/issues/370Add (preprocessor) option for Fernandez-Villaverde et al (2012) type of IRFs ...2013-05-11T11:44:55ZJohannes PfeiferAdd (preprocessor) option for Fernandez-Villaverde et al (2012) type of IRFs in stoch_simulA frequent question is how to generate IRFs at order=3 that look like the ones in Fernandez-Villaverde et al (2012) "Risk matters". I will add a corresponding code over the next two weeks. But a preprocessor option would still be needed....A frequent question is how to generate IRFs at order=3 that look like the ones in Fernandez-Villaverde et al (2012) "Risk matters". I will add a corresponding code over the next two weeks. But a preprocessor option would still be needed. There are two issues that need to be discussed.
1. What should be the naming of the option? I would suggest something like `ergodic_mean_irf` as the IRFs are computed relative to the ergodic mean.
2. Should we allow for flexibility in the number of periods over which to compute the ergodic mean? If yes, we would need another option `ergodic_mean_periods`
https://git.dynare.org/Dynare/dynare/-/issues/338Clarify and potentially disentangle role played by conf_sig2019-11-21T08:36:43ZJohannes PfeiferClarify and potentially disentangle role played by conf_sigAccording to the manual, conf_sig by default is 0.9 for forecast, but after global_initialization, it is 0.6. conditional_forecast has an option with the same name and default 0.8 according to the manual.
According to the manual, conf_sig by default is 0.9 for forecast, but after global_initialization, it is 0.6. conditional_forecast has an option with the same name and default 0.8 according to the manual.
https://git.dynare.org/Dynare/dynare/-/issues/332Add functionality to compute function on posterior2015-10-12T05:18:33ZJohannes PfeiferAdd functionality to compute function on posteriorCurrently, it is very hard to compute a user defined function on the posterior draws. A user asked me if we could add a functionality where the user specifies a function name which is executed on each posterior draw when we compute poste...Currently, it is very hard to compute a user defined function on the posterior draws. A user asked me if we could add a functionality where the user specifies a function name which is executed on each posterior draw when we compute posterior moments. For such a function call, we would need to clearly specify the interface. We might want to provide M_, oo_, bayestopt_, estim_params_ and the current parameter draw as generic inputs (and nothing else). The tricky part consists of specifying the output arguments and making sure we can save them. One way would be to only accept one output argument and save it to the ii element of a cell array. By putting multiple outputs into a structure, the user could still effectively save multiple outputs while keeping a clearly specified interface for us.
Upon going over all draws, we would just save the cell array to the disk. It would be up to the user to make sense of the saved stuff.
4.5https://git.dynare.org/Dynare/dynare/-/issues/317Terminology: Updated Variables2013-04-10T09:22:49ZJohannes PfeiferTerminology: Updated VariablesI find the term "updated variables" currently used in the figure description and the manual very nonstandard. Googling it delivered mostly Dynare results. I would suggest to rename it to the more standard "filtered variables". However, a...I find the term "updated variables" currently used in the figure description and the manual very nonstandard. Googling it delivered mostly Dynare results. I would suggest to rename it to the more standard "filtered variables". However, at the same time the variable "FilteredVariables" contains, as far as I can see it, not the filtered variables, i.e. E(y_t|t), but rather the one-step ahead forecast E(y_t+1|t) (which is also the plot title).
https://git.dynare.org/Dynare/dynare/-/issues/314Should correlation field of oo_.PosteriorTheoreticalMoments be renamed to aut...2013-03-27T13:13:12ZSébastien VillemotShould correlation field of oo_.PosteriorTheoreticalMoments be renamed to autocorrelation?The current naming is confusing…
The current naming is confusing…
4.4https://git.dynare.org/Dynare/dynare/-/issues/294rework option handling2022-06-02T13:55:11ZSé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 t...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/85Estimation is not deterministic: a seed should be explictly given to random n...2013-04-10T13:42:53ZSébastien VillemotEstimation is not deterministic: a seed should be explictly given to random number generatorCurrently MOD files doing estimation are not deterministic: different runs of the same MOD files don't give the same results, since the seed for random number generator is not the same accross runs.
The easy way to fix that is to set th...Currently MOD files doing estimation are not deterministic: different runs of the same MOD files don't give the same results, since the seed for random number generator is not the same accross runs.
The easy way to fix that is to set the seed in dynare.m. There would be a default value for the seed, or it could be changed through an option/command.
A more subtle way would be to have a seed reset at the top of every major function (estimation, stoch_simul).
More details on the following wiki page:
http://www.dynare.org/DynareWiki/FixingRandomseed
We need to decide which way is the best.