dynare issueshttps://git.dynare.org/Dynare/dynare/-/issues2019-11-14T17:38:13Zhttps://git.dynare.org/Dynare/dynare/-/issues/1389Check detrending engine2019-11-14T17:38:13ZJohannes PfeiferCheck detrending engineThe mod-file
```
//-----------------------------------------------------------------------//
//---------------------- Declaring parameters ---------------------------//
//-----------------------------------------------------------...The mod-file
```
//-----------------------------------------------------------------------//
//---------------------- Declaring parameters ---------------------------//
//-----------------------------------------------------------------------//
parameters delta //depreciation
sigma //intertemporal elasticity
beta //discount factor
alpha //production function parameter
mu //utility parameter
theta //Calvo parameter
epsilon //elasticity
chi //indexation parameter (unused for now)
;
alpha = 0.667;
delta = 0.1;
sigma = 0.25;
beta = 0.96;
mu = 0.2;
theta = 0.5;
epsilon = 15;
chi = 0;
//-----------------------------------------------------------------------//
//----------------------- Declaring variables ---------------------------//
//-----------------------------------------------------------------------//
varexo omega //probability of remaining a worker in the next period
gamma //probability of dieing (once retired)
n //populational growth
x //rate of technological change
M_d //exogenous money supply
;
var lambda //asset distribution in the economy
pi //}these define the marginal propensity of consumption
eps //}by both retirees and workers (I'm using Gertler's notation)
OMEGA //higher case omega
R //gross interest rate
PSI //auxiliar variable
mc //marginal cost
Pi //inflation
Df //nominal dividends
Pf //nominal firm share price
price_disp //price dispersion index
;
//declaring nonstationary variables
trend_var(growth_factor= (1+x)*(1+n)/(1+n)) X; //technological progress
trend_var(growth_factor= (1+x)*(1+n)/(1+x)) N; //population
var(deflator = X*N)
Y //product
C //consumption
K //financial capital
H //non-financial capital
A //assets
;
var(deflator = X) W; //real wage
var(deflator = 1/(X*N)) P PStar; //price level and optimal price set
var(deflator = (X*N)^(1-epsilon)) g1; //auxiliary Calvo variable
var(deflator = (X*N)^(2-epsilon)) g2; //auxiliary Calvo variable
predetermined_variables K; //timing convention
//-----------------------------------------------------------------------//
//------------------------------- Model ---------------------------------//
//-----------------------------------------------------------------------//
model;
// Consumer side
//1
K(+1) = Y - C + (1 - delta)* K;
//2
(lambda - (1 - omega(+1)))*A = omega(+1)*(1-eps*pi)*lambda(-1)*R*A(-1);
//3
pi = 1 - PSI(+1) * (R(+1) * OMEGA(+1))^(sigma - 1) * beta^sigma * pi/pi(+1);
//4
eps * pi = 1 - PSI(+1) * ((R(+1))^(sigma-1)*beta^sigma*gamma(+1))*(eps*pi)/(eps(+1)*pi(+1));
//5
OMEGA = omega + (1-omega)*eps^(1/(1-sigma));
//6
H = N * W + H(+1)/((1+n(+1))*(1+x(+1))*R(+1)*OMEGA(+1)/omega(+1));
//7
C * (1 + mu^sigma * (R(+1)*Pi(+1)/(R(+1)*Pi(+1)-1))^(sigma-1)) = pi * ((1 + (eps/gamma-1) * lambda(-1)) * R * A(-1) + H(-1));
//8
A = K + 1/R * M_d(+1)/P + Pf/P;
//9
PSI = (1 + ((R*Pi-1)/(R*Pi))^(sigma-1) * mu^sigma)^(-1) / (1 + (((R(+1)*Pi(+1))-1)/(R(+1)*Pi(+1)))^(sigma-1) * mu^sigma)^(-1);
// Firm side
//10
Y = (X * N)^alpha * (K)^(1-alpha)/price_disp;
//11
W = alpha * Y / N * mc;
//12
R = (1 - alpha) * Y / K * mc + 1 - delta;
//13
mc = (1/(1-alpha))^(1-alpha)*(1/alpha)^alpha*(W/X)^(1-alpha)*(R-(1-delta))^alpha;
// Calvo pricing
//14
PStar = epsilon/(epsilon-1) * g1/g2;
//15
g1 = P^epsilon * Y * mc + theta*beta * g1(+1);
//16
g2 = P^(epsilon-1) * Y + theta*beta * g2(+1);
//17
P = (theta * P(-1)^(1-epsilon) + (1-theta) * PStar^(1-epsilon))^(1/(1-epsilon));
//18
price_disp = theta*(PStar/P)^(-epsilon)*(P/P(-1))^(epsilon) + (1-theta)*(P/P(-1))^(epsilon)*price_disp(-1);
//19
Pi = P/P(-1);
// Dividends and share prices
Df = P * Y *(1-mc);
Pf(+1) + Df(+1) = R(+1) * Pf;
end;
//-----------------------------------------------------------------------//
//--------------------------- Initial Values ----------------------------//
//-----------------------------------------------------------------------//
initval;
M_d = 1; P =1;
x = 0.01;
n = 0.01;
omega = 0.97;
gamma = 0.9;
lambda =0.3878;
pi =0.2394;
eps =1.2832;
OMEGA =1.0124;
R =1.3968;
PSI =0.9988;
mc =0.9064;
Y =0.7407;
C =0.6857;
K =0.459;
H =1.4279;
A =1.365;
P =0.972;
PStar =0.9364;
W =0.448;
Pi =0.98;
Df =0.0681;
Pf =0.1732;
price_disp=1.0336;
g1 =0.601;
g2 =0.6877;
end;
model_diagnostics;
steady;
endval;
gamma = 0.94;
end;
steady;
simul(periods=300);
```
from http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=14206 does not run with
```
ERROR: the second-order cross partial of equation 14 w.r.t. trend variable X and endogenous variable PStar is not null.
```
but the relevant equation
```
PStar = epsilon/(epsilon-1) * g1/g2;
```
should have the trends specified (as far as I can see). `g1/g2=((X*N)^(1-epsilon))/((X*N)^(2-epsilon)=(XN)^(-1)`, which is the trend for `PStar`.4.6Sébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/1093Discuss changing options_.hp_ngrid2020-01-20T17:41:57ZJohannes PfeiferDiscuss changing options_.hp_ngridThe option `options_.hp_ngrid` is now badly named after introducing a `bandpass_filter` option. It actually governs the number of points used in the inverse Fourier transform for any filter (see #1011).
I would suggest creating a new opt...The option `options_.hp_ngrid` is now badly named after introducing a `bandpass_filter` option. It actually governs the number of points used in the inverse Fourier transform for any filter (see #1011).
I would suggest creating a new option `ifft_points` in the options structure and the preprocessor. For backward compatibility we should keep `hp_ngrid` in the preprocesor, but have it now map into `options_.ifft_points`
4.6Sébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/1252do we need to remove dynamic exception specifications?2019-08-14T12:13:30ZMichelJuillarddo we need to remove dynamic exception specifications?dynamic exceptions specification is now deprecated in C++
In mexFunction, when an unknown exception occurs, Matlab or Octave may crash
Maybe we should remove them from the mexFunction code. I don't see very well their contribution.
dynamic exceptions specification is now deprecated in C++
In mexFunction, when an unknown exception occurs, Matlab or Octave may crash
Maybe we should remove them from the mexFunction code. I don't see very well their contribution.
https://git.dynare.org/Dynare/dynare/-/issues/1210Allow string arrays to be passed to options2018-11-09T14:13:22ZHoutan BastaniAllow string arrays to be passed to optionsFollowing the discussion in #1199, allow the preprocessor to accept string array values: `['a' 'b' 'c']`
Following the discussion in #1199, allow the preprocessor to accept string array values: `['a' 'b' 'c']`
Houtan BastaniHoutan Bastanihttps://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/1377Decide on treatment of qz_criterium in estimation with particle filter2019-06-19T15:37:45ZJohannes PfeiferDecide on treatment of qz_criterium in estimation with particle filterCurrently, if a unit root is present, estimation with `order=2` will result in an error. Using `diffuse_filter` will disable the check, but obviously makes no sense for particle filtering. See http://www.dynare.org/phpBB3/viewtopic.php?f...Currently, if a unit root is present, estimation with `order=2` will result in an error. Using `diffuse_filter` will disable the check, but obviously makes no sense for particle filtering. See http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=131264.6https://git.dynare.org/Dynare/dynare/-/issues/1373Decide on whether evalute_smoother (and others) should set M_.params2019-06-19T15:37:45ZJohannes PfeiferDecide on whether evalute_smoother (and others) should set M_.paramsThis picks up the discussion in https://github.com/DynareTeam/dynare/pull/1372#issuecomment-271336355
I agree with @MichelJuillard that changing `M_.params` in various functions is a bad idea as it makes it hard to trace what was goin...This picks up the discussion in https://github.com/DynareTeam/dynare/pull/1372#issuecomment-271336355
I agree with @MichelJuillard that changing `M_.params` in various functions is a bad idea as it makes it hard to trace what was going on in the mod-file. At the same time, I agree with @rattoma that keeping `M_.params` unchanged when calling `evaluate_smoother` would imply a break with previous versions and therefore mean a loss in backward compatibility. I could live with that, but usually @MichelJuillard prefers to be cautious in the regard. If we want to preserve backward compatibility, we need to make sure that `shock_decomposition` returns `M_` from `evaluate_smoother` to the base workspace, which was broken by https://github.com/DynareTeam/dynare/commit/2f717b5adc5a87f663c5c080f2963d1f65d1933ehttps://git.dynare.org/Dynare/dynare/-/issues/1366Decide on how to deal with mistake in manual regarding updated variables2019-06-19T15:37:45ZJohannes PfeiferDecide on how to deal with mistake in manual regarding updated variablesAccording to the manual, `smoother` triggers the computation of `oo_.UpdatedVariables`. But one actually needs `filtered_vars`. We can either
1. Correct the description in the manual to reflect the code behavior
2. Flag this as a bug...According to the manual, `smoother` triggers the computation of `oo_.UpdatedVariables`. But one actually needs `filtered_vars`. We can either
1. Correct the description in the manual to reflect the code behavior
2. Flag this as a bug as the code deviates from the manual and output `oo_.UpdatedVariables` when only the `smoother` option is specifiedhttps://git.dynare.org/Dynare/dynare/-/issues/1332Decide on how to deal with mh_recover on Octave2019-06-19T15:37:45ZJohannes PfeiferDecide on how to deal with mh_recover on OctaveVarious unit test fail on Octave, because the `mh_recover` option does not work properly under Octave as there are differences in setting the random number generator. We can either
- disable the check in the unit test and accept that th...Various unit test fail on Octave, because the `mh_recover` option does not work properly under Octave as there are differences in setting the random number generator. We can either
- disable the check in the unit test and accept that the behavior of `mh_recover` is different under Octave and Matlab (and then document this)
- or provide an error under Octave when someone tries to use this option4.5https://git.dynare.org/Dynare/dynare/-/issues/1296Decide on whether to save intermediate draws2019-06-19T15:37:47ZJohannes PfeiferDecide on whether to save intermediate drawsWith the move to `posterior_sampling_core` we now by default save the MCMC draws every 50 draws into a temporary file, because we by default set
`posterior_sampler_options.save_tmp_file=1;`
I think this is very inefficient and therefore...With the move to `posterior_sampling_core` we now by default save the MCMC draws every 50 draws into a temporary file, because we by default set
`posterior_sampler_options.save_tmp_file=1;`
I think this is very inefficient and therefore should be 0 by default (same behavior as before the move), with an interface provided to change the option.
@rattoma You added this behavior. Was the reason that `slice` should be treated differently?
https://git.dynare.org/Dynare/dynare/-/issues/1229external functions and third order perturbation2019-06-19T15:37:49ZStéphane Adjemianstepan@adjemian.euexternal functions and third order perturbationIt appears that we did not implement the possibility to use external functions when solving DSGE models at third order. I thought that when the derivates are not provided by the user, Dynare computed the derivates numerically. It seems t...It appears that we did not implement the possibility to use external functions when solving DSGE models at third order. I thought that when the derivates are not provided by the user, Dynare computed the derivates numerically. It seems that this mechanism is not triggered at third order. Is this intentional?
https://git.dynare.org/Dynare/dynare/-/issues/1063Make output of dsge_var_likelihood accessible2019-11-21T08:36:44ZJohannes PfeiferMake output of dsge_var_likelihood accessibleSee the discussions in http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=7315 and http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=2920
See the discussions in http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=7315 and http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=2920
https://git.dynare.org/Dynare/dynare/-/issues/1024Save posterior moments even when moments are constant2019-06-19T15:37:56ZJohannes PfeiferSave posterior moments even when moments are constantIn `covariance_mc_analysis.m` and the like we test whether the moments are constant and, if yes, we store NaN. I don't see the logic of this. All moments are still well-defined (although identical). I would propose to get rid of this che...In `covariance_mc_analysis.m` and the like we test whether the moments are constant and, if yes, we store NaN. I don't see the logic of this. All moments are still well-defined (although identical). I would propose to get rid of this check and always store the computed moments.
https://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/1710num_procs doesn't exist in Matalb R2019b anymore2020-02-22T17:49:35ZMichelJuillardnum_procs doesn't exist in Matalb R2019b anymoreThere is no function ``num_procs``in Matlab release 2019b
``num_procs`` is used in ``default_option_values.m`` to initialize number of threads for ``kronecker.sparse_hessian_times_B_kronecker_C``, ``perfect_foresight_problem`` and ``k_o...There is no function ``num_procs``in Matlab release 2019b
``num_procs`` is used in ``default_option_values.m`` to initialize number of threads for ``kronecker.sparse_hessian_times_B_kronecker_C``, ``perfect_foresight_problem`` and ``k_order_perturbation``
A possible alternative would be an undocumented Matlab feature: ``feature('numcores')``
Undocumented Matlab features are discussed in this old document: http://undocumentedmatlab.com/articles/undocumented-feature-function/ but is still working.https://git.dynare.org/Dynare/dynare/-/issues/1713Decide minimal MATLAB version requirement for Dynare 4.72020-09-03T14:45:14ZSébastien VillemotDecide minimal MATLAB version requirement for Dynare 4.7We need to decide what will be the minimal version of MATLAB required to run Dynare 4.7.
For Dynare 4.6, our policy has been to support MATLAB versions that are at most 10 years old.
Assuming that Dynare 4.7 is released in 2021, keepin...We need to decide what will be the minimal version of MATLAB required to run Dynare 4.7.
For Dynare 4.6, our policy has been to support MATLAB versions that are at most 10 years old.
Assuming that Dynare 4.7 is released in 2021, keeping the same policy would imply raising the minimal MATLAB version to R2011a or R2011b (depending on the exact release date).
But we could also decide to change our policy and support less versions. For example, we could go for a 5-years windows, which would imply R2016a or R2016b. Or we could choose something between 5 and 10 years.
Relevant to this discussion is the list of [MATLAB incompatibilities across versions](https://git.dynare.org/Dynare/dynare/-/wikis/MATLAB-Versions). Here are the main benefits that would bring certain requirements:
- *R2013a*: we could get rid of the hack needed to support `intersect(…, 'stable')`
- *R2014a*: we could easily install the minimal required MATLAB version on modern GNU/Linux systems (currently we need a hack to create an artificial `eth0` device with the correct MAC address)
- *R2016a*: we could drop the support for 32-bit versions, which would halve the size of the Windows installer and simplify the build process
- *R2016b*: we could use automatic broadcasting in many places, instead of the obscure `bsxfun` syntax5.xSébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/1730Consider saving results using -v7.3 flag2020-11-13T13:08:07ZJohannes PfeiferConsider saving results using -v7.3 flagWe may want to consider saving the results of a Dynare run using the `-v7.3` flag, which available after Matlab R2006b. That would help getting around occasional issues with the 2GB file limit otherwise present.We may want to consider saving the results of a Dynare run using the `-v7.3` flag, which available after Matlab R2006b. That would help getting around occasional issues with the 2GB file limit otherwise present.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.
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/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/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/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/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/1770Document optimizers allowing analytic_derivation and fix bugs2021-02-18T15:39:35ZJohannes PfeiferDocument optimizers allowing analytic_derivation and fix bugs- [x] The manual does not state which optimizers employ the analytic gradient. It should be at least `fmincon` (1), `csminwel` (4), `newrat` (5).
- [x] `csminwel` and `newrat` are the two optimizers not shipped with e.g. Matlab. They re...- [x] The manual does not state which optimizers employ the analytic gradient. It should be at least `fmincon` (1), `csminwel` (4), `newrat` (5).
- [x] `csminwel` and `newrat` are the two optimizers not shipped with e.g. Matlab. They rely on calls to
```[~,cost_flag,g1] = penalty_objective_function(x1,fcn,penalty,varargin{:});```
where the third output argument is the gradient. Within `penalty_objective_function` we then have
```
[fval, info, exit_flag, arg1, arg2] = fcn(x, varargin{:});
```
where the gradient `arg1` is the fourth and the Hessian `arg2` the fifth output argument of the underlying objective function. For example
```
function [fval,info,exit_flag,DLIK,Hess,SteadyState,trend_coeff,Model,DynareOptions,BayesInfo,DynareResults] = dsge_likelihood(xparam1,DynareDataset,DatasetInfo,DynareOptions,Model,EstimatedParameters,BayesInfo,BoundsInfo,DynareResults,derivatives_info)
```
This interface creates a problem for Matlab optimizers like `fmincon`, which expect the Jacobian as second and the Hessian as the third function output. Neither the underlying objective nor `penalty_objective_function` conform to this convention. The question is how to address this issue. There are two ways:
1. Add a wrapper function along the line of `penalty_objective_function`, which introduces another layer but would be quite easy to implement.
2. Change the output order of the objective function. This would be cleaner and more efficient, but would require quite massive changes in the code-base
- [x] The current implementation of `analytic_derivation` for `fmincon` in `dynare_minimize_objective` is buggy as it considers the second output `info` to be the gradient.
- [ ] It's not clear whether the treatment of the analytic Jacobian in case of the penalty approach is correct as the Jacobian does not take the penalty into account. We need to check whether these cases are filtered out via `cost_flag`5.xhttps://git.dynare.org/Dynare/dynare/-/issues/1888Rename resid.m2023-07-23T10:34:20ZJohannes PfeiferRename resid.mIn Matlab Online I got the warning
```
Warning: Dynare is not on top of the Matlab/Octave path! This can cause problems because the Dynare implementations of resid.m, and vnorm.m will be overriden.
Warning: I put /MATLAB Add-Ons/Toolbox...In Matlab Online I got the warning
```
Warning: Dynare is not on top of the Matlab/Octave path! This can cause problems because the Dynare implementations of resid.m, and vnorm.m will be overriden.
Warning: I put /MATLAB Add-Ons/Toolboxes/dynare/matlab on top of your Matlab/Ocatve path.
Note that this is a temporary change (i.e. it will not affect future Matlab/Octave sessions).
```
Given that Dynare 6.0 will break backward compatibility with the regularly used syntax `resid(1)`, I would suggest to use this opportunity to rename the underlying Matlab function to something more expressive, which at the same time does not cause a naming conflict with the built-in function.6.xhttps://git.dynare.org/Dynare/dynare/-/issues/1907Decide the minimal required versions of MATLAB and Octave for Dynare 62023-12-04T08:51:40ZSébastien VillemotDecide the minimal required versions of MATLAB and Octave for Dynare 6We need to decide the minimal required versions of MATLAB and Octave for Dynare 6.
Dynare 5 requires at least MATLAB R2014a and Octave 5 (at the source code level for the latter).
Since Dynare 5 was released in January 2022, it means t...We need to decide the minimal required versions of MATLAB and Octave for Dynare 6.
Dynare 5 requires at least MATLAB R2014a and Octave 5 (at the source code level for the latter).
Since Dynare 5 was released in January 2022, it means that upon release we were supporting 8 years of MATLAB (R2014a to R2021b); and we are currently supporting 10 years of MATLAB.
If we were to apply the same policy for Dynare 6, that would mean requiring R2016a. But we could also be more aggressive, which would bring some benefits (see the [MATLAB versions](https://git.dynare.org/Dynare/dynare/-/wikis/MATLAB-Versions) page):
- R2016b would allow us to remove all calls to `bsxfun`, and also to drop the JSONlab toolbox under `contrib/` (provided that we also require Octave 7)
- R2018a would allow us to ship only one flavour of the MEX files (since that version introduced an ABI break)
- R2018b would allow us to use double quoted strings (and thus stop worrying about using single quotes everywhere)
And requiring R2019a would mean moving to 5-years window of MATLAB releases supported, which is already quite a lot.
I think we should go for at least R2016b, and maybe even R2018b.
For Octave, we already require Octave 6 in unstable. I would be inclined to require Octave 7, because that would allow us to drop JSONlab (if we also require MATLAB R2016b). My only concern is that Ubuntu 22.04 LTS ships with Octave 6 (so that may affect you @wmutschl); however note that Ubuntu 24.04 LTS will be released shortly after Dynare 6, and it will include Octave 8.
Waiting for your thoughts on this. We should also ask our institutional users about their constraints.6.xSébastien VillemotSébastien Villemot