dynare issueshttps://git.dynare.org/Dynare/dynare/-/issues2020-03-16T08:27:57Zhttps://git.dynare.org/Dynare/dynare/-/issues/1716Fix bug in contemp_reduced_form of SBVAR2020-03-16T08:27:57ZJohannes Pfeifer Fix bug in contemp_reduced_form of SBVARAs outlined in https://forum.dynare.org/t/different-results-of-a0-using-sbvar/15359 the attached codes crashes due to non-conformable matrices.
[MacroData.mat](/uploads/e30cd873d1add8fc54a1e0e65aa0949d/MacroData.mat)
[constantRecursiveBVAR.mod](/uploads/f7b1c204676a2323d03a467702f6e3c5/constantRecursiveBVAR.mod)As outlined in https://forum.dynare.org/t/different-results-of-a0-using-sbvar/15359 the attached codes crashes due to non-conformable matrices.
[MacroData.mat](/uploads/e30cd873d1add8fc54a1e0e65aa0949d/MacroData.mat)
[constantRecursiveBVAR.mod](/uploads/f7b1c204676a2323d03a467702f6e3c5/constantRecursiveBVAR.mod)https://git.dynare.org/Dynare/dynare/-/issues/1781Check correctness of optimal policy with linear model2021-04-10T09:43:50ZJohannes Pfeifer Check correctness of optimal policy with linear model`stoch_simul` locally sets
if options_.order~=1 && M_.hessian_eq_zero
options_.order = 1;
However, `M_.hessian_eq_zero` only seems to apply to the original model, not the nonlinear one resulting from e.g. `ramsey_model`.
On top of that, the change is local, so `evaluate_planner_objective` will crash, because it expects `order=2`.
The same will happen when declaring `model(linear)`. Note that an additional check is in `stochastic_solvers`.
An example is
[ramsey_test.mod](/uploads/452ae65f88b2dde038ab7a844ec429ed/ramsey_test.mod)`stoch_simul` locally sets
if options_.order~=1 && M_.hessian_eq_zero
options_.order = 1;
However, `M_.hessian_eq_zero` only seems to apply to the original model, not the nonlinear one resulting from e.g. `ramsey_model`.
On top of that, the change is local, so `evaluate_planner_objective` will crash, because it expects `order=2`.
The same will happen when declaring `model(linear)`. Note that an additional check is in `stochastic_solvers`.
An example is
[ramsey_test.mod](/uploads/452ae65f88b2dde038ab7a844ec429ed/ramsey_test.mod)4.7https://git.dynare.org/Dynare/dynare/-/issues/1780Compile from source on Mac M1 Apple Silicon architecture2021-04-08T11:14:06ZWilli Mutschlerwilli@mutschler.euCompile from source on Mac M1 Apple Silicon architectureI got hold of a Mac M1 and cannot compile from source following the instructions in the README.md
I will investigate this further and change the instructions accordingly.I got hold of a Mac M1 and cannot compile from source following the instructions in the README.md
I will investigate this further and change the instructions accordingly.Willi Mutschlerwilli@mutschler.euWilli Mutschlerwilli@mutschler.euhttps://git.dynare.org/Dynare/dynare/-/issues/1779Fix detection of Command Line Tools in macOS installer2021-04-06T10:23:17ZSébastien VillemotFix detection of Command Line Tools in macOS installerIn some circumstances (to be determined), the Dynare installer thinks that CLT are installed, while they are not. The typical error message in this case (in `install.log`) is that `git` is not in the path.
Some instances of this:
- https://forum.dynare.org/t/i-can-t-download-dynare-4-6-3-in-macos/17296/
- https://forum.dynare.org/t/error-while-installing-dynare-4-6-3-mac-os-big-sur/17131/
- https://forum.dynare.org/t/problem-installing-4-6-0-on-macos-catalina/15247/20 (second poster)
- https://forum.dynare.org/t/installation-problems-of-4-6-0-on-macos/15345/20 (second poster)In some circumstances (to be determined), the Dynare installer thinks that CLT are installed, while they are not. The typical error message in this case (in `install.log`) is that `git` is not in the path.
Some instances of this:
- https://forum.dynare.org/t/i-can-t-download-dynare-4-6-3-in-macos/17296/
- https://forum.dynare.org/t/error-while-installing-dynare-4-6-3-mac-os-big-sur/17131/
- https://forum.dynare.org/t/problem-installing-4-6-0-on-macos-catalina/15247/20 (second poster)
- https://forum.dynare.org/t/installation-problems-of-4-6-0-on-macos/15345/20 (second poster)4.7https://git.dynare.org/Dynare/dynare/-/issues/1778Identification toolbox: support measurement errors2021-02-25T14:36:14ZWilli Mutschlerwilli@mutschler.euIdentification toolbox: support measurement errorsThe identification toolbox should be able to support measurement errors.The identification toolbox should be able to support measurement errors.4.72021-02-26Willi Mutschlerwilli@mutschler.euWilli Mutschlerwilli@mutschler.euhttps://git.dynare.org/Dynare/dynare/-/issues/1777Pruned theoretical moments: provide a more detailed decomposition of effects2021-02-18T14:21:27ZWilli Mutschlerwilli@mutschler.euPruned theoretical moments: provide a more detailed decomposition of effectsI think we should provide a more detailed decomposition of theoretical unconditional moments at higher-order with pruning as there might be huge differences between e.g. the second and third order system's moments. So something similar to the output of the `nlma` toolbox:
```sh
THEORETICAL MEAN
VARIABLE MEAN(1st Order Accurate) MEAN(2nd and 3rd Order Accurate)
c 4.8675 29.9263
y 4.8675 29.9263
MEAN(2nd and 3rd Order Accurate) DECOMPOSITION IN LEVEL
VARIABLE Mean(2nd and 3rd Order Accurate) Det. Steady State Risk Adj. from Var. of Future Shock Risk Adj. from Var. of Past Shock
c 29.9263 4.8675 27.8139 -2.7551
y 29.9263 4.8675 27.8139 -2.7551
THEORETICAL STANDARD DEVIATION AND VARIANCE
VARIABLE STD.(1st Order Accurate) STD.(2nd Order Accurate) STD.(3rd Order Accurate) VAR.(1st Order Accurate) VAR.(2nd Order Accurate) VAR.(3rd Order Accurate)
c 14.8060 16.0911 53.0529 219.2180 258.9244 2814.6081
y 3.5188 6.8786 63.4057 12.3816 47.3149 4020.2871
THEORETICAL CORRELATIONS(1st Order Accurate)
Variables c y
c 1.0000 0.5852
y 0.5852 1.0000
THEORETICAL CORRELATIONS(2nd Order Accurate)
Variables c y
c 1.0000 0.5201
y 0.5201 1.0000
THEORETICAL CORRELATIONS(3rd Order Accurate)
Variables c y
c 1.0000 0.8925
y 0.8925 1.0000
THEORETICAL COEFFICIENTS OF AUTOCORRELATION(1st Order Accurate)
Order 1 2 3 4 5
c 0.9602 0.9222 0.8861 0.8518 0.8191
y 0.9960 0.9919 0.9877 0.9834 0.9791
THEORETICAL COEFFICIENTS OF AUTOCORRELATION(2nd Order Accurate)
Order 1 2 3 4 5
c 0.9651 0.9319 0.9001 0.8698 0.8408
y 0.9917 0.9833 0.9747 0.9660 0.9573
THEORETICAL COEFFICIENTS OF AUTOCORRELATION(3rd Order Accurate)
Order 1 2 3 4 5
c 0.9944 0.9891 0.9839 0.9789 0.9741
y 0.9979 0.9958 0.9934 0.9909 0.9882
VARIANCE (3rd Order Accurate) DECOMPOSITION IN PERCENTAGE
VARIABLE Total Risk Adj. Total Amp. Total Risk-Amp. Interplay
c 127.42 32.41 -59.83
y 127.42 12.82 -40.24
COMPLETE VARIANCE (3rd Order Accurate) DECOMPOSITION IN PERCENTAGE
VARIABLE Total Risk Adj. 1st Order Amp. 2nd Order Incre. Amp. 3rd Order Incre. Amp. 1st-3rd Order Incre. Amp. 3rd Order Incre. Risk-Amp. Interplay 1st-3rd Order Incre. Risk-Amp. Interplay
c 127.42 7.79 1.41 22.44 0.76 -30.31 -29.51
y 127.42 0.31 0.87 10.10 1.55 -28.00 -12.24
```I think we should provide a more detailed decomposition of theoretical unconditional moments at higher-order with pruning as there might be huge differences between e.g. the second and third order system's moments. So something similar to the output of the `nlma` toolbox:
```sh
THEORETICAL MEAN
VARIABLE MEAN(1st Order Accurate) MEAN(2nd and 3rd Order Accurate)
c 4.8675 29.9263
y 4.8675 29.9263
MEAN(2nd and 3rd Order Accurate) DECOMPOSITION IN LEVEL
VARIABLE Mean(2nd and 3rd Order Accurate) Det. Steady State Risk Adj. from Var. of Future Shock Risk Adj. from Var. of Past Shock
c 29.9263 4.8675 27.8139 -2.7551
y 29.9263 4.8675 27.8139 -2.7551
THEORETICAL STANDARD DEVIATION AND VARIANCE
VARIABLE STD.(1st Order Accurate) STD.(2nd Order Accurate) STD.(3rd Order Accurate) VAR.(1st Order Accurate) VAR.(2nd Order Accurate) VAR.(3rd Order Accurate)
c 14.8060 16.0911 53.0529 219.2180 258.9244 2814.6081
y 3.5188 6.8786 63.4057 12.3816 47.3149 4020.2871
THEORETICAL CORRELATIONS(1st Order Accurate)
Variables c y
c 1.0000 0.5852
y 0.5852 1.0000
THEORETICAL CORRELATIONS(2nd Order Accurate)
Variables c y
c 1.0000 0.5201
y 0.5201 1.0000
THEORETICAL CORRELATIONS(3rd Order Accurate)
Variables c y
c 1.0000 0.8925
y 0.8925 1.0000
THEORETICAL COEFFICIENTS OF AUTOCORRELATION(1st Order Accurate)
Order 1 2 3 4 5
c 0.9602 0.9222 0.8861 0.8518 0.8191
y 0.9960 0.9919 0.9877 0.9834 0.9791
THEORETICAL COEFFICIENTS OF AUTOCORRELATION(2nd Order Accurate)
Order 1 2 3 4 5
c 0.9651 0.9319 0.9001 0.8698 0.8408
y 0.9917 0.9833 0.9747 0.9660 0.9573
THEORETICAL COEFFICIENTS OF AUTOCORRELATION(3rd Order Accurate)
Order 1 2 3 4 5
c 0.9944 0.9891 0.9839 0.9789 0.9741
y 0.9979 0.9958 0.9934 0.9909 0.9882
VARIANCE (3rd Order Accurate) DECOMPOSITION IN PERCENTAGE
VARIABLE Total Risk Adj. Total Amp. Total Risk-Amp. Interplay
c 127.42 32.41 -59.83
y 127.42 12.82 -40.24
COMPLETE VARIANCE (3rd Order Accurate) DECOMPOSITION IN PERCENTAGE
VARIABLE Total Risk Adj. 1st Order Amp. 2nd Order Incre. Amp. 3rd Order Incre. Amp. 1st-3rd Order Incre. Amp. 3rd Order Incre. Risk-Amp. Interplay 1st-3rd Order Incre. Risk-Amp. Interplay
c 127.42 7.79 1.41 22.44 0.76 -30.31 -29.51
y 127.42 0.31 0.87 10.10 1.55 -28.00 -12.24
```4.7Willi Mutschlerwilli@mutschler.euWilli Mutschlerwilli@mutschler.euhttps://git.dynare.org/Dynare/dynare/-/issues/1776Consistency in variable names2021-02-18T16:11:58ZWilli Mutschlerwilli@mutschler.euConsistency in variable namesI would propose to keep the names of common input and output arguments like `M_`, `options_`, `oo_`, `estim_params_`, `bayestopt_`, `dataset_`, `dataset_info`, `estimation_info` consistent throughout the code base. For instance in `dsge_likelihood.m`, `dsge_var_likelihood.m`, `non_linear_dsge_likelihood` or in the functions of the identification toolbox we use names like `DynareOptions`, or `options` (without underscore). So maybe, right before we release 4.7, we could make the names consistent? This would be a simple text search and replace, but everyone would then need to rebase local branches to this.
I think these are the most important variables (feel free to add to this list):
- `M_`
- `options_`
- `oo_`
- `estim_params_`
- `bayestopt_`
- `dataset_`
- `dataset_info`
- `estimation_info`I would propose to keep the names of common input and output arguments like `M_`, `options_`, `oo_`, `estim_params_`, `bayestopt_`, `dataset_`, `dataset_info`, `estimation_info` consistent throughout the code base. For instance in `dsge_likelihood.m`, `dsge_var_likelihood.m`, `non_linear_dsge_likelihood` or in the functions of the identification toolbox we use names like `DynareOptions`, or `options` (without underscore). So maybe, right before we release 4.7, we could make the names consistent? This would be a simple text search and replace, but everyone would then need to rebase local branches to this.
I think these are the most important variables (feel free to add to this list):
- `M_`
- `options_`
- `oo_`
- `estim_params_`
- `bayestopt_`
- `dataset_`
- `dataset_info`
- `estimation_info`4.8https://git.dynare.org/Dynare/dynare/-/issues/1775Document behavior of smoother2histval (or change it)2021-02-18T10:08:24ZJohannes Pfeifer Document behavior of smoother2histval (or change it)From what I can see, the `smoother` will only store the `M_.orig_endo_nbr` variables for Bayesian estimation. So calling `smoother2histval` will "forget" about the auxiliary variables we introduce. Thus, by convention they will be initialized at their steady state - which differs from the description in the manual that it
>will use these values to construct initial conditions (as if they had been manually entered through histval).
In case of `histval`, the non-mentioned variables would be set to 0.
In contrast, for ML it will work.From what I can see, the `smoother` will only store the `M_.orig_endo_nbr` variables for Bayesian estimation. So calling `smoother2histval` will "forget" about the auxiliary variables we introduce. Thus, by convention they will be initialized at their steady state - which differs from the description in the manual that it
>will use these values to construct initial conditions (as if they had been manually entered through histval).
In case of `histval`, the non-mentioned variables would be set to 0.
In contrast, for ML it will work.4.7https://git.dynare.org/Dynare/dynare/-/issues/1774Create checklist for major releases2021-01-29T14:41:07ZJohannes Pfeifer Create checklist for major releasesThere are things the testsuite currently does not check. For example:
1. We don't have the optimization toolbox, but should run the various optimizers at least once before new releases.
2. Using `optim = ('DerivativeCheck', 'on','FiniteDifferenceType','central')`
allows checking the correctness of analytic Jacobians for `analytic_derivatives/fs2000_analytic_derivation.mod` and `method_of_moments\RBC\RBC_MoM_GMM_gradient_optim.mod`. These tests would fail as Matlab does not allow setting the tolerance lower than the default 1e-6, while we are at 1e-5. But we should nevertheless manually check whether we are within a reasonable tolerance.There are things the testsuite currently does not check. For example:
1. We don't have the optimization toolbox, but should run the various optimizers at least once before new releases.
2. Using `optim = ('DerivativeCheck', 'on','FiniteDifferenceType','central')`
allows checking the correctness of analytic Jacobians for `analytic_derivatives/fs2000_analytic_derivation.mod` and `method_of_moments\RBC\RBC_MoM_GMM_gradient_optim.mod`. These tests would fail as Matlab does not allow setting the tolerance lower than the default 1e-6, while we are at 1e-5. But we should nevertheless manually check whether we are within a reasonable tolerance.4.7https://git.dynare.org/Dynare/dynare/-/issues/1773Performance of local_state_space_iteration_*2021-01-21T16:23:44ZSébastien VillemotPerformance of local_state_space_iteration_*The `local_state_space_iteration_2` MEX is much faster than `local_state_space_iteration_k` at order 2.
This performance differential should be investigated. But it is likely that the Dynare++ engine for simulating the model is not very well optimized.
The solution is either to improve the performance of the Dynare++ code, or to fully rewrite it without using Dynare++ codebase (and by the way, do that in Fortran).
Related to #1768 and #1643.The `local_state_space_iteration_2` MEX is much faster than `local_state_space_iteration_k` at order 2.
This performance differential should be investigated. But it is likely that the Dynare++ engine for simulating the model is not very well optimized.
The solution is either to improve the performance of the Dynare++ code, or to fully rewrite it without using Dynare++ codebase (and by the way, do that in Fortran).
Related to #1768 and #1643.https://git.dynare.org/Dynare/dynare/-/issues/1772Document method of moments toolbox2021-01-21T16:00:20ZSébastien VillemotDocument method of moments toolbox4.7Willi Mutschlerwilli@mutschler.euWilli Mutschlerwilli@mutschler.euhttps://git.dynare.org/Dynare/dynare/-/issues/1769Discuss merging dsge_simulated_theoretical_correlation and dsge_simulated_the...2021-01-17T17:10:16ZJohannes Pfeifer Discuss merging dsge_simulated_theoretical_correlation and dsge_simulated_theoretical_covariance`dsge_simulated_theoretical_covariance` sets `options_.ar = 0` before calling `th_autocovariances`. `dsge_simulated_theoretical_correlation` again calls `th_autocovariances` and therefore recomputes the variance. One call with `options_.nar` would suffice. This inefficiency is even more pronounced at higher order with `pruning` where we need to call `pruned_state_space_system`.
We should either
1. Merge the two functions.
2. Have `dsge_simulated_theoretical_covariance` compute and store everything and only use `dsge_simulated_theoretical_correlation` to fill the fields.`dsge_simulated_theoretical_covariance` sets `options_.ar = 0` before calling `th_autocovariances`. `dsge_simulated_theoretical_correlation` again calls `th_autocovariances` and therefore recomputes the variance. One call with `options_.nar` would suffice. This inefficiency is even more pronounced at higher order with `pruning` where we need to call `pruned_state_space_system`.
We should either
1. Merge the two functions.
2. Have `dsge_simulated_theoretical_covariance` compute and store everything and only use `dsge_simulated_theoretical_correlation` to fill the fields.4.7https://git.dynare.org/Dynare/dynare/-/issues/1766Allow for Herbst-Schorfheide and DS-MH sampler2021-01-13T13:37:47ZJohannes Pfeifer Allow for Herbst-Schorfheide and DS-MH samplerSee https://forum.dynare.org/t/new-samplers-and-mode-compute-methods/17267/7See https://forum.dynare.org/t/new-samplers-and-mode-compute-methods/17267/74.7https://git.dynare.org/Dynare/dynare/-/issues/1763Ramsey: document potential problems with auxiliary variables for timeless per...2021-01-13T17:07:03ZJohannes Pfeifer Ramsey: 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/164.7https://git.dynare.org/Dynare/dynare/-/issues/1759Decide whether to drop Windows 7 support2021-03-23T13:48:34ZSébastien VillemotDecide whether to drop Windows 7 supportCurrently, we officially support three versions of Windows: 7, 8.1 and 10.
Mainstream support for Windows 7 expired on 2015, and extended support expired on January 2020.
Until January 2023, Microsoft still provides so-called “Extended Security Updates”, but this requires a paid subscription (which is probably quite expensive, and thus only accessible to large institutions).
The decision to drop official Dynare support for Windows 7 therefore mostly depends on whether our institutional users have already moved away from Windows 7, or are still postponing the inevitable upgrade.
Note that dropping support for Windows 7 does not mean that Dynare would stop working on that platform (at least until we introduce some breaking change). It simply means that there would be no testing and no guarantee of functionality on that platform.Currently, we officially support three versions of Windows: 7, 8.1 and 10.
Mainstream support for Windows 7 expired on 2015, and extended support expired on January 2020.
Until January 2023, Microsoft still provides so-called “Extended Security Updates”, but this requires a paid subscription (which is probably quite expensive, and thus only accessible to large institutions).
The decision to drop official Dynare support for Windows 7 therefore mostly depends on whether our institutional users have already moved away from Windows 7, or are still postponing the inevitable upgrade.
Note that dropping support for Windows 7 does not mean that Dynare would stop working on that platform (at least until we introduce some breaking change). It simply means that there would be no testing and no guarantee of functionality on that platform.4.8https://git.dynare.org/Dynare/dynare/-/issues/1758Discuss moving all mod-file output to folder `M_.dname`2021-02-15T18:52:53ZJohannes Pfeifer Discuss moving all mod-file output to folder `M_.dname`The discussion in https://git.dynare.org/Dynare/dynare/-/merge_requests/1793 points to a design problem of the generally useful `M_.dname`-option: We still save various output-files like the `_results.mat`-file in the main folder. So the `dname`-saving logic does not fully work. For `4.7` I would propose moving all Dynare-generated output to a subfolder of `M_.dname` to get a clean root directory. We have increasingly moved to the direction in the past, e.g. with the $\LaTeX$-files.
I would then also propose to offer a preprocessor command line option `dname` to set this at the preprocessor-level. This would allow solving the `json`-issue discussed at https://git.dynare.org/Dynare/dynare/-/merge_requests/1793The discussion in https://git.dynare.org/Dynare/dynare/-/merge_requests/1793 points to a design problem of the generally useful `M_.dname`-option: We still save various output-files like the `_results.mat`-file in the main folder. So the `dname`-saving logic does not fully work. For `4.7` I would propose moving all Dynare-generated output to a subfolder of `M_.dname` to get a clean root directory. We have increasingly moved to the direction in the past, e.g. with the $\LaTeX$-files.
I would then also propose to offer a preprocessor command line option `dname` to set this at the preprocessor-level. This would allow solving the `json`-issue discussed at https://git.dynare.org/Dynare/dynare/-/merge_requests/17934.7https://git.dynare.org/Dynare/dynare/-/issues/1754Add model_info for non-block models2020-11-30T21:27:51ZJohannes Pfeifer Add model_info for non-block modelsSee https://forum.dynare.org/t/perfect-foresight-model-what-variables-predetermined-and-forward-looking/17028/2 for a starting point. The main issue is auxiliary variablesSee https://forum.dynare.org/t/perfect-foresight-model-what-variables-predetermined-and-forward-looking/17028/2 for a starting point. The main issue is auxiliary variables4.7https://git.dynare.org/Dynare/dynare/-/issues/1749Fix testsuite for Octave2020-11-26T12:31:54ZWilli Mutschlerwilli@mutschler.euFix testsuite for OctaveOn master, some mod files do not yet run with Octave due to e.g. missing functions and other small bugs. Here is an (updated) list, when I push fixes I'll update the list:
- [ ] analytic_derivatives/BrockMirman_PertParamsDerivs (on RHEL/CentOS, but not Fedora, with KRONFLAG=-1)
- [x] estimation/method_of_moments/* (use nanmean instead of mean(x,'omitnan'; randstream not implemented in Octave;maybe other errors)
- [ ] bgp/* (many problems, probably numerical imprecision, also due to incompatibilities from and differences in toolboxes such as optim)On master, some mod files do not yet run with Octave due to e.g. missing functions and other small bugs. Here is an (updated) list, when I push fixes I'll update the list:
- [ ] analytic_derivatives/BrockMirman_PertParamsDerivs (on RHEL/CentOS, but not Fedora, with KRONFLAG=-1)
- [x] estimation/method_of_moments/* (use nanmean instead of mean(x,'omitnan'; randstream not implemented in Octave;maybe other errors)
- [ ] bgp/* (many problems, probably numerical imprecision, also due to incompatibilities from and differences in toolboxes such as optim)4.7Willi Mutschlerwilli@mutschler.euWilli Mutschlerwilli@mutschler.euhttps://git.dynare.org/Dynare/dynare/-/issues/1746Create a MEX equivalent to minreal from the control toolbx2021-01-18T18:28:41ZSébastien VillemotCreate a MEX equivalent to minreal from the control toolbxSee the comments in `get_minimal_state_representation.m`.See the comments in `get_minimal_state_representation.m`.4.7Sébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/1745Adding support for dates in perfect_foresight_setup2020-09-25T08:38:53ZMichelJuillardAdding support for dates in perfect_foresight_setupThe user should be able to control the dates of the dseries produced by ``perfect_foresight_solver``
- Currently, `histval``,``histval_file`` and ``initval_file`` pass a ``dseries` to ``perfect_foresight_setup``
- By default, ``perfect_foresight_setup`` should be consistent with the dates of this ``dseries``
- dates must be permitted in ``histval`` instead of only signed integers
- ``first_obs``: sets the dates used for the first initial conditions. Must be consistent with ``histval`` or ``histval_file`` if they are used
- ``first_simulation_period``: sets the dates used for the first period of the simulation. It is an alternative to specifying ``first_obs`` and must be consistent if ``first_obs``is also used as an option. Values for initial conditions before this date must be available. Must be consistent with ``histval`` or ``histval_file`` if they are used.
- ``last_simulation_period``: sets the date of the last period of simulation. It is an alternative to specifying ``periods`` and must be consistent if ``periods``is also used as an option. Data for terminal conditions past the last period must be availableThe user should be able to control the dates of the dseries produced by ``perfect_foresight_solver``
- Currently, `histval``,``histval_file`` and ``initval_file`` pass a ``dseries` to ``perfect_foresight_setup``
- By default, ``perfect_foresight_setup`` should be consistent with the dates of this ``dseries``
- dates must be permitted in ``histval`` instead of only signed integers
- ``first_obs``: sets the dates used for the first initial conditions. Must be consistent with ``histval`` or ``histval_file`` if they are used
- ``first_simulation_period``: sets the dates used for the first period of the simulation. It is an alternative to specifying ``first_obs`` and must be consistent if ``first_obs``is also used as an option. Values for initial conditions before this date must be available. Must be consistent with ``histval`` or ``histval_file`` if they are used.
- ``last_simulation_period``: sets the date of the last period of simulation. It is an alternative to specifying ``periods`` and must be consistent if ``periods``is also used as an option. Data for terminal conditions past the last period must be available4.7MichelJuillardMichelJuillard