dynare issueshttps://git.dynare.org/Dynare/dynare/-/issues2022-12-08T11:12:15Zhttps://git.dynare.org/Dynare/dynare/-/issues/1877Document Windows restrictions on passing quoted strings at command line2022-12-08T11:12:15ZJohannes PfeiferDocument Windows restrictions on passing quoted strings at command lineFor example, under Windows the invocation
```
dynare sw2007nw_dsge -Ddatafile_name='"data94q1.mat"'
```
is cut down to
```
Calling Dynare with arguments: -Ddatafile_name="data94q1.mat"
```
i.e. the second layer of quoted strings is lost....For example, under Windows the invocation
```
dynare sw2007nw_dsge -Ddatafile_name='"data94q1.mat"'
```
is cut down to
```
Calling Dynare with arguments: -Ddatafile_name="data94q1.mat"
```
i.e. the second layer of quoted strings is lost. The most robust workaround is to handle the strings at the mod-file level, e.g.
```
estimation(datafile='@{datafile_name}')
```
instead of trying to have the quote in the `datafile_name`.https://git.dynare.org/Dynare/dynare/-/issues/1844algebra at the beginning of conditional_forecast2022-03-02T17:15:11ZMichelJuillardalgebra at the beginning of conditional_forecastIn the algebraic description of ``conditional_forecast`` in section 4.20 of the manual, lagged uncontrolled endogenous variables are missingIn the algebraic description of ``conditional_forecast`` in section 4.20 of the manual, lagged uncontrolled endogenous variables are missing6.xStéphane Adjemianstepan@adjemian.euStéphane Adjemianstepan@adjemian.euhttps://git.dynare.org/Dynare/dynare/-/issues/1816Document VAR and PAC routines2024-01-29T20:46:19ZSébastien VillemotDocument VAR and PAC routines6.xStéphane Adjemianstepan@adjemian.euStéphane Adjemianstepan@adjemian.euhttps://git.dynare.org/Dynare/dynare/-/issues/1811Clarify auxiliary variable types2021-09-17T14:39:12ZJohannes PfeiferClarify auxiliary variable types- [x] Move https://archives.dynare.org/DynareWiki/AuxiliaryVariables to new Wiki
- [x] According to https://git.dynare.org/Dynare/dynare/-/blob/master/matlab/isauxiliary.m there are more than the 6 documented types
- [x] Check https://gi...- [x] Move https://archives.dynare.org/DynareWiki/AuxiliaryVariables to new Wiki
- [x] According to https://git.dynare.org/Dynare/dynare/-/blob/master/matlab/isauxiliary.m there are more than the 6 documented types
- [x] Check https://git.dynare.org/Dynare/dynare/-/blob/master/matlab/disp_dr.m for consistency (type 10 is missing)
- [x] Check whether type >8 still actually arises5.xhttps://git.dynare.org/Dynare/dynare/-/issues/1808Update or remove https://archives.dynare.org/DynareWiki/EquationsTags2021-08-17T10:04:38ZJohannes PfeiferUpdate or remove https://archives.dynare.org/DynareWiki/EquationsTagsThe information there seems outdated or redundant, but it is still linked from the manual.The information there seems outdated or redundant, but it is still linked from the manual.5.xhttps://git.dynare.org/Dynare/dynare/-/issues/1807Manual: fix broken references2021-09-20T16:34:02ZJohannes PfeiferManual: fix broken referencesThe manual contains a bunch of broken internal references that seems to occur when referencing something that does not have a natural anchor. For example
```
.. _quote-note:
.. note::
Note on Quotes
```
and
```
...The manual contains a bunch of broken internal references that seems to occur when referencing something that does not have a natural anchor. For example
```
.. _quote-note:
.. note::
Note on Quotes
```
and
```
.. _VarianceDecomposition:
``VarianceDecomposition``
Decomposition of variance (unconditional variance, i.e. at
horizon infinity). [#f5]_
``VarianceDecompositionME``
Same as `VarianceDecomposition`_, but contains
```
do not work5.xhttps://git.dynare.org/Dynare/dynare/-/issues/1799Document Occbin features2021-08-17T10:25:56ZJohannes PfeiferDocument Occbin features5.xJohannes PfeiferJohannes Pfeiferhttps://git.dynare.org/Dynare/dynare/-/issues/1772Document method of moments toolbox2021-08-17T10:51:11ZSébastien VillemotDocument method of moments toolbox5.xWilli Mutschlerwilli@mutschler.euWilli Mutschlerwilli@mutschler.euhttps://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/1764Document storage of decision rules at order ≥ 42021-03-12T14:00:54ZSébastien VillemotDocument storage of decision rules at order ≥ 4The reference manual documents the matrix storage of decision rules up to order 3. We should give a short description of the storage for higher order (simply the generalisation of order 3, which already uses Dynare++ storage).The reference manual documents the matrix storage of decision rules up to order 3. We should give a short description of the storage for higher order (simply the generalisation of order 3, which already uses Dynare++ storage).5.xSébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/1763Ramsey: document potential problems with auxiliary variables for timeless per...2021-08-17T10:24:37ZJohannes PfeiferRamsey: document potential problems with auxiliary variables for timeless perspectiveSee https://forum.dynare.org/t/timing-perfect-foresight-ramsey/17157/16See https://forum.dynare.org/t/timing-perfect-foresight-ramsey/17157/165.xhttps://git.dynare.org/Dynare/dynare/-/issues/1707Macro commands that take no arguments have spurious parentheses appended to t...2024-01-17T20:31:14ZSébastien VillemotMacro commands that take no arguments have spurious parentheses appended to their synopsisSee for example the definition of `@#else`, `@#endif`, `@#endfor`, `@#echomacrovars` in the reference manual.See for example the definition of `@#else`, `@#endif`, `@#endfor`, `@#echomacrovars` in the reference manual.6.xhttps://git.dynare.org/Dynare/dynare/-/issues/1688fix `basic_plan`, `flip_plan` in doc2024-01-29T20:57:50ZHoutan Bastanifix `basic_plan`, `flip_plan` in docThe calling structure for both of these functions runs off the end of the pageThe calling structure for both of these functions runs off the end of the page6.xStéphane Adjemianstepan@adjemian.euStéphane Adjemianstepan@adjemian.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/1682Sort out correct order of blocks in perfect foresight Ramsey and document it2020-01-10T14:48:20ZJohannes PfeiferSort 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 `stea...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/1680Adapt evaluate_planner_objective.m to higher order and perfect foresight2022-09-07T12:30:49ZJohannes PfeiferAdapt evaluate_planner_objective.m to higher order and perfect foresightSupersedes https://git.dynare.org/Dynare/dynare/issues/564 and is related to https://git.dynare.org/Dynare/dynare/issues/1678
See also https://forum.dynare.org/t/evaluate-planner-objective-in-non-linear-model/15492
Remaining:
- [x] fixi...Supersedes https://git.dynare.org/Dynare/dynare/issues/564 and is related to https://git.dynare.org/Dynare/dynare/issues/1678
See also https://forum.dynare.org/t/evaluate-planner-objective-in-non-linear-model/15492
Remaining:
- [x] fixing or documenting the regression in behavior introduced in e880d1bc. In contrast to previous behavior `histval` will be ignored. `planner_objective_value` now returns conditional and unconditional welfare instead of welfare for different values of the Lagrange multiplier. (done in !1923)
- [x] the question of an interface for setting the initial condition (https://git.dynare.org/Dynare/preprocessor/-/issues/64)
- [x] Adding higher order results to `evaluate_planner_objective`
- [x] Compute unconditional welfare at order>2
- [x] Documenting the recent changes6.xNormann RionNormann Rionhttps://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.m2021-08-19T08:37:33ZJohannes PfeiferProvide 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...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 PfeiferJohannes Pfeiferhttps://git.dynare.org/Dynare/dynare/-/issues/1672conditional_forecast should save its output in oo_2019-11-29T16:11:56ZSébastien Villemotconditional_forecast should save its output in oo_Currently, `conditional_forecast` stores its output in a file. This is inconsistent with the rest of Dynare commands, and renders the post-processing of this data less robust, because we have to reload that file from the hard drive (with...Currently, `conditional_forecast` stores its output in a file. This is inconsistent with the rest of Dynare commands, and renders the post-processing of this data less robust, because we have to reload that file from the hard drive (without the guarantee that it comes from the same Dynare session).
The output should be saved in a field of `oo_` (without changing the structure).
`plot_ic_forecast` needs to be adapted. `shock_decomposition` as well, once #1657 is done.
The various fields should also be documented.4.6https://git.dynare.org/Dynare/dynare/-/issues/1669Restore index of functions and commands in the manual2019-12-03T14:45:18ZSébastien VillemotRestore index of functions and commands in the manualIn the texinfo manual, there used to be an index for functions and commands (see https://www.dynare.org/manual/Command-and-Function-Index.html#Command-and-Function-Index).
This has been lost in the conversion to sphinx, and should there...In the texinfo manual, there used to be an index for functions and commands (see https://www.dynare.org/manual/Command-and-Function-Index.html#Command-and-Function-Index).
This has been lost in the conversion to sphinx, and should therefore be restored.
By the way, if this is technically feasible, and index of variables (fields of `M_`, `oo_`, …) would also be useful.4.6Houtan BastaniHoutan Bastani