dynare issueshttps://git.dynare.org/Dynare/dynare/issues2019-06-19T15:38:10Zhttps://git.dynare.org/Dynare/dynare/issues/641Support new MEX compilation under Windows (MATLAB >= 8.3/R2014a)2019-06-19T15:38:10ZSébastien VillemotSupport new MEX compilation under Windows (MATLAB >= 8.3/R2014a)In MATLAB 8.3/R2014a, the `mex` command has been rewritten. In particular, all the `mexopts.bat` logic is now obsolete (but still works, with a warning).
We should aim at supporting the new infrastructure.
See also http://www.dynare.org/DynareWiki/ConfigureMatlabWindowsForMexCompilation and issue #640.
In MATLAB 8.3/R2014a, the `mex` command has been rewritten. In particular, all the `mexopts.bat` logic is now obsolete (but still works, with a warning).
We should aim at supporting the new infrastructure.
See also http://www.dynare.org/DynareWiki/ConfigureMatlabWindowsForMexCompilation and issue #640.
https://git.dynare.org/Dynare/dynare/issues/640Provide support for Cygwin 64-bit2019-06-19T15:38:10ZSébastien VillemotProvide support for Cygwin 64-bitRecent versions of Cygwin include a 64-bit version, installed under `c:\cygwin64` by default.
We should support this configuration, at least in two places:
- when compiling MEX files with `use_dll`; see http://www.dynare.org/DynareWiki/ConfigureMatlabWindowsForMexCompilation
- in `README.md`, for people compiling from source
Recent versions of Cygwin include a 64-bit version, installed under `c:\cygwin64` by default.
We should support this configuration, at least in two places:
- when compiling MEX files with `use_dll`; see http://www.dynare.org/DynareWiki/ConfigureMatlabWindowsForMexCompilation
- in `README.md`, for people compiling from source
4.5https://git.dynare.org/Dynare/dynare/issues/648Compiling dynare++ into a Python library using SWIG2019-06-19T15:38:10ZStéphane Adjemianstepan@dynare.orgCompiling dynare++ into a Python library using SWIG*Created by: davidrpugh*
All,
I would be very interested in seeing if it is possible to use http://www.swig.org/ to wrap Dynare++ to create a Python library tentatively called PyDynare++ A longer term goal would be to link PyDynare++ with the excellent PyMC library for doing Bayesian MCMC estimation to create a Python-based substitute for the Matlab-Octave version of Dynare.
Does this sound like a project that would be interesting/useful to the larger Dynare community?
*Created by: davidrpugh*
All,
I would be very interested in seeing if it is possible to use http://www.swig.org/ to wrap Dynare++ to create a Python library tentatively called PyDynare++ A longer term goal would be to link PyDynare++ with the excellent PyMC library for doing Bayesian MCMC estimation to create a Python-based substitute for the Matlab-Octave version of Dynare.
Does this sound like a project that would be interesting/useful to the larger Dynare community?
https://git.dynare.org/Dynare/dynare/issues/651block the use of estimated_params_init and estimated_param_bounds when no est...2019-06-19T15:38:10ZJohannes Pfeifer block the use of estimated_params_init and estimated_param_bounds when no estimated_params-block is presentOtherwise, a crash results. See http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=5638
Otherwise, a crash results. See http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=5638
4.5MichelJuillardMichelJuillardhttps://git.dynare.org/Dynare/dynare/issues/652Support passing a vector to the power operator on a dseries2019-06-19T15:38:08ZHoutan BastaniSupport passing a vector to the power operator on a dseriesUnlike the other arithmetic operations, power does not allow element-wise operations when passed a matrix. I.e.
```
ts1=dseries([1;2;3], '1999y', {'MyVar1'}, {'MyVar\_1'});
ts1/[1:3]’
ts1-[1:3]’
ts1*[1:3]’
ts1+[1:3]’
```
are all ok. But,
```
ts1^[1:3]’
```
causes an error
Unlike the other arithmetic operations, power does not allow element-wise operations when passed a matrix. I.e.
```
ts1=dseries([1;2;3], '1999y', {'MyVar1'}, {'MyVar\_1'});
ts1/[1:3]’
ts1-[1:3]’
ts1*[1:3]’
ts1+[1:3]’
```
are all ok. But,
```
ts1^[1:3]’
```
causes an error
4.5Stéphane Adjemianstepan@dynare.orgStéphane Adjemianstepan@dynare.orghttps://git.dynare.org/Dynare/dynare/issues/654Fix generation of dates when only one data series is used2019-06-19T15:38:08ZJohannes Pfeifer Fix generation of dates when only one data series is usedIn that case, load_xls_file_data crashes because the variable name is taken as the first date. See http://www.dynare.org/phpBB3/viewtopic.php?f=2&t=5650
In that case, load_xls_file_data crashes because the variable name is taken as the first date. See http://www.dynare.org/phpBB3/viewtopic.php?f=2&t=5650
4.5https://git.dynare.org/Dynare/dynare/issues/655Fix unconditional_forecast values derived from conditional_forecast command2019-06-19T15:38:08ZJohannes Pfeifer Fix unconditional_forecast values derived from conditional_forecast commandThe `unconditional_forecast`-command seems to produce incorrect forecasts when used together with `initval`. This can be seen in the following mod-file where it yields different results than the `forecast`-command (which appear sensible).
```
// See fs2000.mod in the examples/ directory for details on the model
var m P c e W R k d n l gy_obs gp_obs y dA;
varexo e_a e_m;
parameters alp bet gam mst rho psi del;
alp = 0.33;
bet = 0.99;
gam = 0.003;
mst = 1.011;
rho = 0.7;
psi = 0.787;
del = 0.02;
model;
dA = exp(gam+e_a);
log(m) = (1-rho)*log(mst) + rho*log(m(-1))+e_m;
-P/(c(+1)*P(+1)*m)+bet*P(+1)*(alp*exp(-alp*(gam+log(e(+1))))*k^(alp-1)*n(+1)^(1-alp)+(1-del)*exp(-(gam+log(e(+1)))))/(c(+2)*P(+2)*m(+1))=0;
W = l/n;
-(psi/(1-psi))*(c*P/(1-n))+l/n = 0;
R = P*(1-alp)*exp(-alp*(gam+e_a))*k(-1)^alp*n^(-alp)/W;
1/(c*P)-bet*P*(1-alp)*exp(-alp*(gam+e_a))*k(-1)^alp*n^(1-alp)/(m*l*c(+1)*P(+1)) = 0;
c+k = exp(-alp*(gam+e_a))*k(-1)^alp*n^(1-alp)+(1-del)*exp(-(gam+e_a))*k(-1);
P*c = m;
m-1+d = l;
e = exp(e_a);
y = k(-1)^alp*n^(1-alp)*exp(-alp*(gam+e_a));
gy_obs = dA*y/y(-1);
gp_obs = (P/P(-1))*m(-1)/dA;
end;
initval;
k = 6;
m = mst;
P = 2.25;
c = 0.45;
e = 1;
W = 4;
R = 1.02;
d = 0.85;
n = 0.19;
l = 0.86;
y = 0.6;
gy_obs = exp(gam);
gp_obs = exp(-gam);
dA = exp(gam);
end;
shocks;
var e_a; stderr 0.014;
var e_m; stderr 0.005;
end;
steady;
check;
stoch_simul(irf=0);
conditional_forecast_paths;
var gy_obs;
periods 1 2 3:5;
values 0.01 -0.02 0;
var gp_obs;
periods 1:5;
values 0.05;
end;
initval;
k = 6;
m = mst;
P = 2.25;
c = 0.45;
e = 1;
W = 4;
R = 1.02;
d = 0.85;
n = 0.19;
l = 0.86;
y = 0.6;
gy_obs = exp(gam);
gp_obs = exp(-gam);
dA = exp(gam);
end;
conditional_forecast(parameter_set=calibration, controlled_varexo=(e_a,e_m));
plot_conditional_forecast(periods=10) gy_obs gp_obs;
forecast(periods=40);
```
The problem seems to come from lines 139-143 of `imcforecast` where the initial values are supposed to be translated into deviations from steady state:
```
else
InitState(:,1) = zeros(M_.endo_nbr,1);
trend = repmat(oo_.steady_state(oo_.dr.order_var),1,options_cond_fcst.periods+1);
graph_title='Calibration';
end
```
However, the initial state is always 0, regardless of the initial values given in initval. Rather the initial values appear in `trend` and are later added to the forecasts. As a result, if started outside of steady state, there is no tendency of forecasts to return to steady state. This is exactly what can be seen in the flat forecasts in `forecasts.uncond.Mean` in the above mod-file. In contrast, the `forecast`-command yields the correct return to steady state.
My reading is that the problem also affects the conditional forecasts.
See also http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=5617
The `unconditional_forecast`-command seems to produce incorrect forecasts when used together with `initval`. This can be seen in the following mod-file where it yields different results than the `forecast`-command (which appear sensible).
```
// See fs2000.mod in the examples/ directory for details on the model
var m P c e W R k d n l gy_obs gp_obs y dA;
varexo e_a e_m;
parameters alp bet gam mst rho psi del;
alp = 0.33;
bet = 0.99;
gam = 0.003;
mst = 1.011;
rho = 0.7;
psi = 0.787;
del = 0.02;
model;
dA = exp(gam+e_a);
log(m) = (1-rho)*log(mst) + rho*log(m(-1))+e_m;
-P/(c(+1)*P(+1)*m)+bet*P(+1)*(alp*exp(-alp*(gam+log(e(+1))))*k^(alp-1)*n(+1)^(1-alp)+(1-del)*exp(-(gam+log(e(+1)))))/(c(+2)*P(+2)*m(+1))=0;
W = l/n;
-(psi/(1-psi))*(c*P/(1-n))+l/n = 0;
R = P*(1-alp)*exp(-alp*(gam+e_a))*k(-1)^alp*n^(-alp)/W;
1/(c*P)-bet*P*(1-alp)*exp(-alp*(gam+e_a))*k(-1)^alp*n^(1-alp)/(m*l*c(+1)*P(+1)) = 0;
c+k = exp(-alp*(gam+e_a))*k(-1)^alp*n^(1-alp)+(1-del)*exp(-(gam+e_a))*k(-1);
P*c = m;
m-1+d = l;
e = exp(e_a);
y = k(-1)^alp*n^(1-alp)*exp(-alp*(gam+e_a));
gy_obs = dA*y/y(-1);
gp_obs = (P/P(-1))*m(-1)/dA;
end;
initval;
k = 6;
m = mst;
P = 2.25;
c = 0.45;
e = 1;
W = 4;
R = 1.02;
d = 0.85;
n = 0.19;
l = 0.86;
y = 0.6;
gy_obs = exp(gam);
gp_obs = exp(-gam);
dA = exp(gam);
end;
shocks;
var e_a; stderr 0.014;
var e_m; stderr 0.005;
end;
steady;
check;
stoch_simul(irf=0);
conditional_forecast_paths;
var gy_obs;
periods 1 2 3:5;
values 0.01 -0.02 0;
var gp_obs;
periods 1:5;
values 0.05;
end;
initval;
k = 6;
m = mst;
P = 2.25;
c = 0.45;
e = 1;
W = 4;
R = 1.02;
d = 0.85;
n = 0.19;
l = 0.86;
y = 0.6;
gy_obs = exp(gam);
gp_obs = exp(-gam);
dA = exp(gam);
end;
conditional_forecast(parameter_set=calibration, controlled_varexo=(e_a,e_m));
plot_conditional_forecast(periods=10) gy_obs gp_obs;
forecast(periods=40);
```
The problem seems to come from lines 139-143 of `imcforecast` where the initial values are supposed to be translated into deviations from steady state:
```
else
InitState(:,1) = zeros(M_.endo_nbr,1);
trend = repmat(oo_.steady_state(oo_.dr.order_var),1,options_cond_fcst.periods+1);
graph_title='Calibration';
end
```
However, the initial state is always 0, regardless of the initial values given in initval. Rather the initial values appear in `trend` and are later added to the forecasts. As a result, if started outside of steady state, there is no tendency of forecasts to return to steady state. This is exactly what can be seen in the flat forecasts in `forecasts.uncond.Mean` in the above mod-file. In contrast, the `forecast`-command yields the correct return to steady state.
My reading is that the problem also affects the conditional forecasts.
See also http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=5617
4.5https://git.dynare.org/Dynare/dynare/issues/656reporting example in manual2019-06-19T15:38:08ZMichelJuillardreporting example in manualThe example under reporting in the manual is not current. Option 'color' is now graphLineColor and the color code must be spelled out
The example under reporting in the manual is not current. Option 'color' is now graphLineColor and the color code must be spelled out
4.5Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/issues/658Restore backward compatibility of mode_file-option2019-06-19T15:38:08ZJohannes Pfeifer Restore backward compatibility of mode_file-optionLine 202 of `dynare_estimation_init.m` reads:
`if isequal(mode_file.parameter_names, bayestopt_.name)`
But it seems that `mode_file.parameter_names` was not set in previous versions of Dynare, leading to crashes and missing backward compatibility. It seems that an additional check whether this field exists is required.
Line 202 of `dynare_estimation_init.m` reads:
`if isequal(mode_file.parameter_names, bayestopt_.name)`
But it seems that `mode_file.parameter_names` was not set in previous versions of Dynare, leading to crashes and missing backward compatibility. It seems that an additional check whether this field exists is required.
https://git.dynare.org/Dynare/dynare/issues/657produce & print original model (without auxiliary variable substitutions)2019-06-19T15:38:08ZHoutan Bastaniproduce & print original model (without auxiliary variable substitutions)For inclusion in reports (or just general interest), produce the original model and be able to print it in latex.
Add option to include calibrated values in parentheses next to variables in the report.
For inclusion in reports (or just general interest), produce the original model and be able to print it in latex.
Add option to include calibrated values in parentheses next to variables in the report.
4.5Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/issues/662Update and fix gsa/set_shocks_param.m2019-06-19T15:38:08ZJohannes Pfeifer Update and fix gsa/set_shocks_param.mApart from an obvious typo (`Sigma_e_` instead `Sigma_e`) it seems as if that file is still missing the update to reflect calibrated covariances (#511).
Apart from an obvious typo (`Sigma_e_` instead `Sigma_e`) it seems as if that file is still missing the update to reflect calibrated covariances (#511).
4.5Marco RattoMarco Rattohttps://git.dynare.org/Dynare/dynare/issues/664Identification and var_exo_det2019-06-19T15:38:08ZJohannes Pfeifer Identification and var_exo_detBoth are not compatible because in calls to the dynamic file the components of `oo_.exo_det_steady_state` neglect x.
Either filter out those cases or make them compatible.
Both are not compatible because in calls to the dynamic file the components of `oo_.exo_det_steady_state` neglect x.
Either filter out those cases or make them compatible.
4.5Marco RattoMarco Rattohttps://git.dynare.org/Dynare/dynare/issues/665support looser syntax for creating dates2019-06-19T15:38:08ZHoutan Bastanisupport looser syntax for creating datesRight now, the following syntax works:
`dates(4, [1990; 1991], [1; 2]);`
but
`dates(4, [1990 1991], [1 2]);`
doesn't. What is important is that the arrays passed be vectors, not that they be column vectors or row vectors. We should ease the syntax to accept both, just checking that they are indeed vectors.
Right now, the following syntax works:
`dates(4, [1990; 1991], [1; 2]);`
but
`dates(4, [1990 1991], [1 2]);`
doesn't. What is important is that the arrays passed be vectors, not that they be column vectors or row vectors. We should ease the syntax to accept both, just checking that they are indeed vectors.
4.5Stéphane Adjemianstepan@dynare.orgStéphane Adjemianstepan@dynare.orghttps://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/669fullpage LaTeX package causes compilation to break on Windows (is output by w...2019-06-19T15:38:08ZHoutan Bastanifullpage LaTeX package causes compilation to break on Windows (is output by write_latex_dynamic_model)Try to repeat error and find a work around if indeed it is not distributed with MikTex
Try to repeat error and find a work around if indeed it is not distributed with MikTex
4.5Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/issues/670Fix handling of prefiltering and trends in non_linear_dsge_likelihood2019-06-19T15:38:08ZJohannes Pfeifer Fix 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/671misc changes to dates/dseries2019-06-19T15:38:08ZHoutan Bastanimisc changes to dates/dseries- dates: rename `time` field to something more descriptive. Perhaps `data`
- dates: remove `ndat` field. Should have method that provides this information instead
- dseries: remove `nobs` field. Should have method that provides this information instead
- dseries: remove `vobs` field. Should have method that provides this information instead
- dates: rename `time` field to something more descriptive. Perhaps `data`
- dates: remove `ndat` field. Should have method that provides this information instead
- dseries: remove `nobs` field. Should have method that provides this information instead
- dseries: remove `vobs` field. Should have method that provides this information instead
4.5Stéphane Adjemianstepan@dynare.orgStéphane Adjemianstepan@dynare.orghttps://git.dynare.org/Dynare/dynare/issues/672Use pgfplotstable for report tables instead of latex tables2019-06-19T15:38:08ZHoutan BastaniUse pgfplotstable for report tables instead of latex tablesBefore making the change, ensure it's distributed in MikTex
http://pgfplots.sourceforge.net/pgfplotstable.pdf
Before making the change, ensure it's distributed in MikTex
http://pgfplots.sourceforge.net/pgfplotstable.pdf
4.5Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/issues/673when creating a report with only one table, tmpRepDir is not created and it c...2019-06-19T15:38:08ZHoutan Bastaniwhen creating a report with only one table, tmpRepDir is not created and it crashesSee Eleonora's email from 18h30 27/6/2014
See Eleonora's email from 18h30 27/6/2014
4.5Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/issues/675Fix bug in dsge_likelihood related to analytic_derivation2019-06-19T15:38:08ZJohannes Pfeifer Fix bug in dsge_likelihood related to analytic_derivationSee http://www.dynare.org/pipermail/dev/2014-May/003793.html
See http://www.dynare.org/pipermail/dev/2014-May/003793.html
4.5Marco RattoMarco Ratto