dynare issueshttps://git.dynare.org/Dynare/dynare/-/issues2020-11-13T09:06:11Zhttps://git.dynare.org/Dynare/dynare/-/issues/1243Allow model-local variables with block and bytecode2020-11-13T09:06:11ZJohannes PfeiferAllow model-local variables with block and bytecodeWe currently return the error
`'block' or 'bytecode' options are not yet compatible with pound expressions`
Given that `steady_state_model` cannot be used for handling parameter dependence in the `perfect_foresight`, model-local variable...We currently return the error
`'block' or 'bytecode' options are not yet compatible with pound expressions`
Given that `steady_state_model` cannot be used for handling parameter dependence in the `perfect_foresight`, model-local variables seem the only way to go. We should therefore allow them.
@houtanb Where exactly is the challenge from the proprocessor-side?
5.xSébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/1173Support estimation under optimal policy2021-07-22T13:33:48ZJohannes PfeiferSupport estimation under optimal policySee http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=8071See http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=80715.xSébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/1114create contributions.md describing how to contribute to dynare2021-09-01T12:56:19ZHoutan Bastanicreate contributions.md describing how to contribute to dynare5.xStéphane Adjemianstepan@adjemian.euStéphane Adjemianstepan@adjemian.euhttps://git.dynare.org/Dynare/dynare/-/issues/1044Clear up option mh_posterior_mode_estimation2021-09-22T15:30:36ZJohannes PfeiferClear up option mh_posterior_mode_estimationSee the question at http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=7235
Does anyone know what it does?
Looking at the codes in `dynare_estimation_1.m` this option seems to skip mode computation and directly runs the MCMC, using the pr...See the question at http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=7235
Does anyone know what it does?
Looking at the codes in `dynare_estimation_1.m` this option seems to skip mode computation and directly runs the MCMC, using the prior mode as the starting point and the prior variances for computing the inverse Hessian for the MCMC. In case of the mode not existing, the prior mean is used.
But already before doing so, it sets
```
oo_.posterior.optimization.mode = xparam1;
oo_.posterior.optimization.Variance = [];
```
That is, the mode saved is based on the starting values given for MCMC and no variance is saved. This looks like a a bug as the MCMC starts with values that are only set after this assignment.
Finally, this option runs the MCMC and calls `CutSample.m` before returning. What is the point of just estimating the MCMC starting at the prior mode and providing no output?
We should either document the option and add a preprocessor command or get rid of it.5.xhttps://git.dynare.org/Dynare/dynare/-/issues/1045Clarify interface for evaluate_planner_objective.m2021-09-14T14:08:35ZMichelJuillardClarify interface for evaluate_planner_objective.mIt works OK for evaluation at the steady state, but the way to set histval and shocks in first period is confusingIt works OK for evaluation at the steady state, but the way to set histval and shocks in first period is confusing5.xNormann RionNormann Rionhttps://git.dynare.org/Dynare/dynare/-/issues/1004Make initvalf and histvalf compatible with translation to one-lag problem2021-09-22T07:54:34ZJohannes PfeiferMake initvalf and histvalf compatible with translation to one-lag problemWe currently have both `initvalf` and `histvalf` but with auxiliary variable substitution it is not clear to me how separate the two and how to properly initialize a model. Also, `histvalf` automatically takes care of auxiliary variables...We currently have both `initvalf` and `histvalf` but with auxiliary variable substitution it is not clear to me how separate the two and how to properly initialize a model. Also, `histvalf` automatically takes care of auxiliary variables while `initvalf` does not.
Related to #6175.xhttps://git.dynare.org/Dynare/dynare/-/issues/831Improve homotopy2021-09-17T08:41:25ZStéphane Adjemianstepan@adjemian.euImprove homotopy- [X] Display more informations about the progress of the algorithm.
- [X] Do not display warnings.
- [X] Set verbosity to 0 when entering in the homotopy.
- [X] Fix homotopy with `block` and `bytecode` options.
- [x] Fix display of info...- [X] Display more informations about the progress of the algorithm.
- [X] Do not display warnings.
- [X] Set verbosity to 0 when entering in the homotopy.
- [X] Fix homotopy with `block` and `bytecode` options.
- [x] Fix display of informations with `bytecode options`.5.xStéphane Adjemianstepan@adjemian.euStéphane Adjemianstepan@adjemian.euhttps://git.dynare.org/Dynare/dynare/-/issues/713Block recursive prior definitions2021-09-21T15:21:04ZJohannes PfeiferBlock recursive prior definitionsRecursive specification of priors seem to be currently allowed, e.g.
```
a1 0.2,1E-5,1, BETA_PDF,0.5,0.1;
a2 0.5,1E-5,1, a1 BETA_PDF,0.85,0.1;
```
where the upper bound for `a2` is actually set based on the value `a1` has in the parame...Recursive specification of priors seem to be currently allowed, e.g.
```
a1 0.2,1E-5,1, BETA_PDF,0.5,0.1;
a2 0.5,1E-5,1, a1 BETA_PDF,0.85,0.1;
```
where the upper bound for `a2` is actually set based on the value `a1` has in the parameter initialization section (and never updates it during estimation based on new values of `a1`). But the user clearly intends to make the prior conditional, which Dynare does not allow. We should block this kind of behavior in the preprocessor, because the actual behavior is unexpected.
Sidenote: would it be sensible to allow for conditional priors at some point in the future?5.xhttps://git.dynare.org/Dynare/dynare/-/issues/569Integrate OccBin2021-07-21T16:03:22ZHoutan BastaniIntegrate OccBinhttps://github.com/lucashare/occbin
https://www2.bc.edu/matteo-iacoviello/research_files/TOOLKIT_PAPER.pdfhttps://github.com/lucashare/occbin
https://www2.bc.edu/matteo-iacoviello/research_files/TOOLKIT_PAPER.pdf5.xMarco RattoMarco Rattohttps://git.dynare.org/Dynare/dynare/-/issues/444Document remaining options of nonlinear filters2021-08-17T10:25:22ZStéphane Adjemianstepan@adjemian.euDocument remaining options of nonlinear filtersWe need to describe and discuss all the available options in `options_.particle`. Setting options has been introduced in https://git.dynare.org/Dynare/dynare/-/merge_requests/1884. Still to do
- [x] Adjust the wiki to reflect the new way...We need to describe and discuss all the available options in `options_.particle`. Setting options has been introduced in https://git.dynare.org/Dynare/dynare/-/merge_requests/1884. Still to do
- [x] Adjust the wiki to reflect the new way of setting these options
- [x] Add information to the manual (a link to the wiki is the minimum)5.xJohannes PfeiferJohannes Pfeiferhttps://git.dynare.org/Dynare/dynare/-/issues/1708Preprocessor fails to parse dates with negative date2020-06-30T12:10:36ZMichelJuillardPreprocessor 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...```
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/1706Fix wrong computation in third-order approximation in pruned_state_space.m2020-04-06T08:19:17ZJohannes PfeiferFix wrong computation in third-order approximation in pruned_state_space.mMattermost discussion 06/02/20Mattermost discussion 06/02/204.6Willi Mutschlerwilli@mutschler.euWilli Mutschlerwilli@mutschler.euhttps://git.dynare.org/Dynare/dynare/-/issues/1705Fix, clean and speed up discretionary_policy routines2020-02-12T16:18:04ZJohannes PfeiferFix, 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_.en...As 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 PfeiferJohannes Pfeiferhttps://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_d...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-12-02T21:55:49ZSé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 arguments2022-12-06T17:47:52ZHoutan 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 sim...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``` 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 Bastani