dynare issueshttps://git.dynare.org/Dynare/dynare/issues2020-02-17T17:41:25Zhttps://git.dynare.org/Dynare/dynare/issues/1708Preprocessor fails to parse dates with negative date2020-02-17T17:41:25ZMichelJuillardPreprocessor fails to parse dates with negative date```
dates('-4Y');
```
translates in
```
dates('-dates('4Y')');
```
and
```
'-4Y'
```
translates in
```
'-dates('4Y')';
```
See attached *.mod file[test_negative_date.mod](/uploads/bd77dc2c55701ffd505b432a2071f86d/test_negative_date.mod)
The problem didn't appear in 4.5.7```
dates('-4Y');
```
translates in
```
dates('-dates('4Y')');
```
and
```
'-4Y'
```
translates in
```
'-dates('4Y')';
```
See attached *.mod file[test_negative_date.mod](/uploads/bd77dc2c55701ffd505b432a2071f86d/test_negative_date.mod)
The problem didn't appear in 4.5.74.6Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/issues/1705Fix, clean and speed up discretionary_policy routines2020-02-12T16:18:04ZJohannes Pfeifer Fix, clean and speed up discretionary_policy routinesAs is `discretionary_policy_1.m` has various issues
1. At its end, we have
```
function ys=NondistortionarySteadyState(M_)
if exist([M_.fname,'_steadystate.m'],'file')
eval(['ys=',M_.fname,'_steadystate.m;'])
else
ys=zeros(M_.endo_nbr,1);
end
```
which seems to miss the case of a `steady_state_model`-block. It's also not clear why we have this in any case. At the end of the function, we write `ys` based on this input. But throughout the function, like in
```
[U,Uy,W] = feval([M_.fname,'.objective.static'],zeros(endo_nbr,1),[], M_.params);
```
we assume the steady state to be 0.
2. The handling of error codes should be nested into the `print_info`-framework as opposed to always issuing errors.
3. The function is very verbatim in terms of providing diagnostics. That is useful in standalone code, but a bottleneck when run in a loop like `estimation` where we only want to discard infeasible draws without providing diagnostics.
4. The order of some checks is strange. We do computations on the model before checking e.g. whether the number of instruments is valid. We should be able to do this without computing the Jacobian. Also a check like this should only be done once in the context of estimation and does not belong into the core engine. This suggests a different factorization.
Related to https://git.dynare.org/Dynare/dynare/issues/1173As is `discretionary_policy_1.m` has various issues
1. At its end, we have
```
function ys=NondistortionarySteadyState(M_)
if exist([M_.fname,'_steadystate.m'],'file')
eval(['ys=',M_.fname,'_steadystate.m;'])
else
ys=zeros(M_.endo_nbr,1);
end
```
which seems to miss the case of a `steady_state_model`-block. It's also not clear why we have this in any case. At the end of the function, we write `ys` based on this input. But throughout the function, like in
```
[U,Uy,W] = feval([M_.fname,'.objective.static'],zeros(endo_nbr,1),[], M_.params);
```
we assume the steady state to be 0.
2. The handling of error codes should be nested into the `print_info`-framework as opposed to always issuing errors.
3. The function is very verbatim in terms of providing diagnostics. That is useful in standalone code, but a bottleneck when run in a loop like `estimation` where we only want to discard infeasible draws without providing diagnostics.
4. The order of some checks is strange. We do computations on the model before checking e.g. whether the number of instruments is valid. We should be able to do this without computing the Jacobian. Also a check like this should only be done once in the context of estimation and does not belong into the core engine. This suggests a different factorization.
Related to https://git.dynare.org/Dynare/dynare/issues/11734.6Johannes Pfeifer Johannes Pfeifer https://git.dynare.org/Dynare/dynare/issues/1701det_conditional_forecast doesn't set set options_.qz_criterium2020-02-03T17:37:21ZMichelJuillarddet_conditional_forecast doesn't set set options_.qz_criteriumWhen ``det_conditional_forecast`` is used by itself in a *.mod file as in the example of the manual options_.qz_criterium isn't set.
We should have
```
options_.qz_criterium = 1+1e-6;
```
at the beginning of the functionWhen ``det_conditional_forecast`` is used by itself in a *.mod file as in the example of the manual options_.qz_criterium isn't set.
We should have
```
options_.qz_criterium = 1+1e-6;
```
at the beginning of the function4.6https://git.dynare.org/Dynare/dynare/issues/1699Welfare under optimal discretionary policy not computed2020-01-30T14:50:04ZSébastien VillemotWelfare under optimal discretionary policy not computedAt least with `dennis_1.mod` and `Gali_discretion.mod` from `tests/discretionary_policy/`, the welfare (as stored in `oo_.planner_objective_value`) is a `NaN`. This is a regression from 4.5.
Unfortunately, the test at the end of `Gali_discretion.mod` did not catch the problem, because of the specific evaluation rules for `NaN`. This should also be fixed with some call to `isnan()`.At least with `dennis_1.mod` and `Gali_discretion.mod` from `tests/discretionary_policy/`, the welfare (as stored in `oo_.planner_objective_value`) is a `NaN`. This is a regression from 4.5.
Unfortunately, the test at the end of `Gali_discretion.mod` did not catch the problem, because of the specific evaluation rules for `NaN`. This should also be fixed with some call to `isnan()`.4.6Sébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/issues/1697Regression in LMMCP perfect foresight solver2020-01-27T15:16:45ZSébastien VillemotRegression in LMMCP perfect foresight solverThe simulation in `tests/lmmcp/rbcii.mod` fails to converge. The same file works with 4.5.
Once this is fixed, a check that convergence has indeed been obtained should be added, so that regressions may be detected earlier in the future.The simulation in `tests/lmmcp/rbcii.mod` fails to converge. The same file works with 4.5.
Once this is fixed, a check that convergence has indeed been obtained should be added, so that regressions may be detected earlier in the future.4.6Sébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/issues/1696fix parsing of user-provided command line arguments2020-02-11T17:15:49ZHoutan Bastanifix parsing of user-provided command line argumentsMatlab is actually quite good about keeping user-provided arguments together. See:
```
>> dynare example1 '-DA="nthn thnth"' -DB=[1,2, .3] -DB=( oe )
-DA="nthn thnth"
-DB=[1,2, .3]
-DB=( oe )
```
The output above comes from simply printing the arguments of `varargin`.
We should be able to thus simply add single quotes around every user-provided argument in `dynare.m` and pass these directly to the preprocessor for processing. We'd then require that all strings be double-quoted and could potentially even handle macro expressions (not just base values) in `-D` arguments.Matlab is actually quite good about keeping user-provided arguments together. See:
```
>> dynare example1 '-DA="nthn thnth"' -DB=[1,2, .3] -DB=( oe )
-DA="nthn thnth"
-DB=[1,2, .3]
-DB=( oe )
```
The output above comes from simply printing the arguments of `varargin`.
We should be able to thus simply add single quotes around every user-provided argument in `dynare.m` and pass these directly to the preprocessor for processing. We'd then require that all strings be double-quoted and could potentially even handle macro expressions (not just base values) in `-D` arguments.4.6Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/issues/1695Calib_Smoother options specify sheet and range2020-01-13T17:40:52ZCamilo MarchesiniCalib_Smoother options specify sheet and range```calib_smoother``` currently does not support options related to 'sheet' and 'range' of the Excel spreadsheet. However, these options can be included in the ```estimation``` call. It could be useful to include them also in the call to ```calib_smoother``` .
```calib_smoother``` currently does not support options related to 'sheet' and 'range' of the Excel spreadsheet. However, these options can be included in the ```estimation``` call. It could be useful to include them also in the call to ```calib_smoother``` .
4.6https://git.dynare.org/Dynare/dynare/issues/1694Identification tests fail for old matlab2020-01-24T17:25:41ZWilli Mutschlerwilli@mutschler.euIdentification tests fail for old matlabSome identification tests fail under MATLAB R2009b, see https://git.dynare.org/Dynare/dynare/-/jobs/12770. Some functions need to be replaced.Some identification tests fail under MATLAB R2009b, see https://git.dynare.org/Dynare/dynare/-/jobs/12770. Some functions need to be replaced.4.6Willi Mutschlerwilli@mutschler.euWilli Mutschlerwilli@mutschler.euhttps://git.dynare.org/Dynare/dynare/issues/1692Update doc for dynasave and dynatype2020-01-06T10:05:46ZHoutan BastaniUpdate doc for dynasave and dynatypeSplitting up #1691, update the doc for 4.6 and leave the other changes for 4.7Splitting up #1691, update the doc for 4.6 and leave the other changes for 4.74.6Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/issues/1691Allow dynasave and dynatype to also save simulated exogenous variables2020-01-06T13:59:31ZJohannes Pfeifer Allow dynasave and dynatype to also save simulated exogenous variablesThe documentation does not state that this is not allowed. We would need to
* [x] Adjust the Matlab code
* [ ] Make the documentation more explicit
* [x] Allow for the `var_list_` to accept exogenousThe documentation does not state that this is not allowed. We would need to
* [x] Adjust the Matlab code
* [ ] Make the documentation more explicit
* [x] Allow for the `var_list_` to accept exogenous4.6https://git.dynare.org/Dynare/dynare/issues/1690Return an error if nonlinear filters are used with trends or prefilter2020-01-13T17:40:52ZStéphane Adjemianstepan@adjemian.euReturn an error if nonlinear filters are used with trends or prefilterSee discussion [here](https://git.dynare.org/Dynare/dynare/commit/76e3c6ca687dbbb55f5e8b47cc8a613b039d80ed#note_10148).See discussion [here](https://git.dynare.org/Dynare/dynare/commit/76e3c6ca687dbbb55f5e8b47cc8a613b039d80ed#note_10148).4.6Stéphane Adjemianstepan@adjemian.euStéphane Adjemianstepan@adjemian.euhttps://git.dynare.org/Dynare/dynare/issues/1689Clarify licensing information for identification stuff2020-01-24T14:41:20ZSébastien VillemotClarify licensing information for identification stuffSee !1689
The information should be added in the corresponding headers, and in `license.txt`See !1689
The information should be added in the corresponding headers, and in `license.txt`4.6Willi Mutschlerwilli@mutschler.euWilli Mutschlerwilli@mutschler.euhttps://git.dynare.org/Dynare/dynare/issues/1687Interface and documentation for new shock decomposition functionalities2020-01-22T17:18:39ZSébastien VillemotInterface and documentation for new shock decomposition functionalitiesImplement the preprocessor changes needed for !1655.
The test `tests/shock_decomposition/ls2003_plot.mod` will need to be adapted for the new `squeeze_shock_decomposition` command.
Also add the related documentation.Implement the preprocessor changes needed for !1655.
The test `tests/shock_decomposition/ls2003_plot.mod` will need to be adapted for the new `squeeze_shock_decomposition` command.
Also add the related documentation.4.6Sébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/issues/1686Add interface to set LaTeX-name of optimal_policy_discount_factor2019-12-18T16:46:52ZJohannes Pfeifer Add interface to set LaTeX-name of optimal_policy_discount_factorI would propose an option `planner_discount_latex_name` to `ramsey_model` that takes a string and sets `M_.param_names_tex{strmatch('optimal_policy_discount_factor',M_.param_names,'exact')}` as well as the internal field in the preprocessor output used for the `write_latex_*` commands. Unfortunately, this needs to be a LaTeX string that can contain a backslash. If the parser cannot easily handle this, we should not implement it.I would propose an option `planner_discount_latex_name` to `ramsey_model` that takes a string and sets `M_.param_names_tex{strmatch('optimal_policy_discount_factor',M_.param_names,'exact')}` as well as the internal field in the preprocessor output used for the `write_latex_*` commands. Unfortunately, this needs to be a LaTeX string that can contain a backslash. If the parser cannot easily handle this, we should not implement it.4.6Sébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/issues/1685Fix write_latex_dynamic_model(write_equation_tags) for ramsey_model2020-01-06T17:33:31ZJohannes Pfeifer Fix write_latex_dynamic_model(write_equation_tags) for ramsey_modelWhen using `ramsey_model`, the `M_.ramsey_eq_nbr` planner FOCs are written before the `M_.orig_eq_nbr` private sector FOCs for which the equation tags have been provided. But the equation tags are printed for the first `M_.orig_eq_nbr` equations, not for the `M_.ramsey_eq_nbr+1:M_.eq_nbr` ones.When using `ramsey_model`, the `M_.ramsey_eq_nbr` planner FOCs are written before the `M_.orig_eq_nbr` private sector FOCs for which the equation tags have been provided. But the equation tags are printed for the first `M_.orig_eq_nbr` equations, not for the `M_.ramsey_eq_nbr+1:M_.eq_nbr` ones.4.6Sébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/issues/1683Provide preprocessor warning that `simul` is deprecated2019-12-13T17:22:32ZJohannes Pfeifer Provide preprocessor warning that `simul` is deprecatedWe provide a preprocessor warning that `ramsey_policy` is deprecated. We should provide a similar warning if `simul` is called that the recommended syntax is `perfect_foresight_setup` and `perfect_foresight_solver`.We provide a preprocessor warning that `ramsey_policy` is deprecated. We should provide a similar warning if `simul` is called that the recommended syntax is `perfect_foresight_setup` and `perfect_foresight_solver`.4.6Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/issues/1682Sort out correct order of blocks in perfect foresight Ramsey and document it2020-01-10T14:48:20ZJohannes Pfeifer Sort out correct order of blocks in perfect foresight Ramsey and document itUsually `steady` after `initval` computes a steady state. But with `ramsey_model`, one seems to need the `ramsey_model(planner_discount=0.99);` statement before the call to steady and therefore `initval`. Also, it is not clear what `steady` does in this case. Is it the private sector equilibrium steady state or the Ramsey steady state that is computed.
Relevant test case: `optimal_policy/nk_ramsey_det.mod`Usually `steady` after `initval` computes a steady state. But with `ramsey_model`, one seems to need the `ramsey_model(planner_discount=0.99);` statement before the call to steady and therefore `initval`. Also, it is not clear what `steady` does in this case. Is it the private sector equilibrium steady state or the Ramsey steady state that is computed.
Relevant test case: `optimal_policy/nk_ramsey_det.mod`4.6https://git.dynare.org/Dynare/dynare/issues/1681Model incorrectly detected as linear for ramsey_model2019-12-13T19:54:26ZJohannes Pfeifer Model incorrectly detected as linear for ramsey_modelI am experiencing trouble with `ramsey_model` in `Ramsey_Example.mod`. If I use `stoch_simul` via `dynare Ramsey_Example -DOptimal_policy=0`, then
```
M_.nonzero_hessian_eqs = [0 1 2 5 6 7 9 10 11];
M_.hessian_eq_zero = isempty(M_.nonzero_hessian_eqs);
```
but with `ramsey_model` via `dynare Ramsey_Example`
```
M_.nonzero_hessian_eqs = [];
M_.hessian_eq_zero = isempty(M_.nonzero_hessian_eqs);
```
So for some reason the model is detected as being linear, which it is notI am experiencing trouble with `ramsey_model` in `Ramsey_Example.mod`. If I use `stoch_simul` via `dynare Ramsey_Example -DOptimal_policy=0`, then
```
M_.nonzero_hessian_eqs = [0 1 2 5 6 7 9 10 11];
M_.hessian_eq_zero = isempty(M_.nonzero_hessian_eqs);
```
but with `ramsey_model` via `dynare Ramsey_Example`
```
M_.nonzero_hessian_eqs = [];
M_.hessian_eq_zero = isempty(M_.nonzero_hessian_eqs);
```
So for some reason the model is detected as being linear, which it is not4.6Sébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/issues/1679Document epilogue2020-01-22T09:33:16ZSébastien VillemotDocument epilogueIt should also be added to the new features wiki page.It should also be added to the new features wiki page.4.6Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/issues/1678Provide interface to access evaluate_planner_objective.m2020-01-10T14:48:18ZJohannes Pfeifer Provide interface to access evaluate_planner_objective.mAs noted in https://git.dynare.org/Dynare/dynare/issues/564#note_9765, `ramsey_policy` only allows for `order=1`. The solution is to replace it by
```
ramsey_model;
stoch_simul(order=2)
```
But the downside of this approach is that we do not compute the welfare function in this case and one cannot add it to the model-block. For that reason, we need to provide the user with an interface to call `evaluate_planner_objective`As noted in https://git.dynare.org/Dynare/dynare/issues/564#note_9765, `ramsey_policy` only allows for `order=1`. The solution is to replace it by
```
ramsey_model;
stoch_simul(order=2)
```
But the downside of this approach is that we do not compute the welfare function in this case and one cannot add it to the model-block. For that reason, we need to provide the user with an interface to call `evaluate_planner_objective`4.6Johannes Pfeifer Johannes Pfeifer