dynare issueshttps://git.dynare.org/Dynare/dynare/-/issues2020-01-28T14:01:41Zhttps://git.dynare.org/Dynare/dynare/-/issues/1688fix `basic_plan`, `flip_plan` in doc2020-01-28T14:01:41ZHoutan 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 page4.7Stéphane Adjemianstepan@adjemian.euStéphane Adjemianstepan@adjemian.euhttps://git.dynare.org/Dynare/dynare/-/issues/1693Various improvements in Sphinx doc2020-01-08T16:24:40ZHoutan BastaniVarious improvements in Sphinx doc- see if we can use https://pypi.org/project/sphinxcontrib-matlabdomain/ instead of `MatComm` and `MatlabVar` defined in `doc/manual/utils/dynare_dom.py`
- if not, add new domain entry to differentiate between MATLAB commands and MATLAB functions
- find way to fix output of Matlab Commands so the options conform to the true type used for Dynare Command options
- code block:
- many general problems with highlighting: e.g. `end` is highlighted when it is MATLAB code but the corresponding `for` is not highlighted
- despite being in `doc/manual/utils/dynare_lex.py`, `var` is not highlighted in code blocks
- ideally find a programmatic way to fill `doc/manual/utils/dynare_lex.py` from the `rst` files instead of having to update it by hand- see if we can use https://pypi.org/project/sphinxcontrib-matlabdomain/ instead of `MatComm` and `MatlabVar` defined in `doc/manual/utils/dynare_dom.py`
- if not, add new domain entry to differentiate between MATLAB commands and MATLAB functions
- find way to fix output of Matlab Commands so the options conform to the true type used for Dynare Command options
- code block:
- many general problems with highlighting: e.g. `end` is highlighted when it is MATLAB code but the corresponding `for` is not highlighted
- despite being in `doc/manual/utils/dynare_lex.py`, `var` is not highlighted in code blocks
- ideally find a programmatic way to fill `doc/manual/utils/dynare_lex.py` from the `rst` files instead of having to update it by hand4.7https://git.dynare.org/Dynare/dynare/-/issues/1698Allow checking linearity for perfect foresight models2020-02-14T15:05:47ZJohannes Pfeifer Allow checking linearity for perfect foresight modelsThe linearity check underlying `model(linear)` is based on the Hessian of the model. But we don’t compute the Hessian for a perfect foresight simulation, hence the check is skipped. See line 799 of `preprocessor/src/ModFile.cc`.
That can be problematic in case of nonlinearities like a ZLB constraint in an otherwise linear model. The solver assumes that the Jacobian is the same at every period, and the constraint is not enforced.
For very large perfect foresight models, we actually don’t want to put the Hessian in the generated dynamic file, because compiling it can be very time consuming. Hence the fix is not straightforward.
I would suggest to add a way of testing this. One option would be trigger the Hessian computation with a `debug` option or something like this. For example, we could use the already present command line option `debug`.The linearity check underlying `model(linear)` is based on the Hessian of the model. But we don’t compute the Hessian for a perfect foresight simulation, hence the check is skipped. See line 799 of `preprocessor/src/ModFile.cc`.
That can be problematic in case of nonlinearities like a ZLB constraint in an otherwise linear model. The solver assumes that the Jacobian is the same at every period, and the constraint is not enforced.
For very large perfect foresight models, we actually don’t want to put the Hessian in the generated dynamic file, because compiling it can be very time consuming. Hence the fix is not straightforward.
I would suggest to add a way of testing this. One option would be trigger the Hessian computation with a `debug` option or something like this. For example, we could use the already present command line option `debug`.4.7https://git.dynare.org/Dynare/dynare/-/issues/1700Proposal for a generalized solver2020-01-30T09:53:09ZMichelJuillardProposal for a generalized solverModel inversion and deterministic conditional forecast solve the same mathematical problem: solving a (non-)linear system where the identity of the unknown variables change from period to period. I suggest to create a unique function that would solve such problems.
``general_solver`` would take at least the following arguments:
* y: endogenous variables (matrix)
* x: exogenous variables (matrix) [possible concatenation of exo_det variables to the right]
* model: model (function handle)
* i_endo_flip: flip variables indices in endogenous variables (vector)
* i_exo_flip: flip variables indices in exogenous variables (vector)
### Conventions
1. there are as many endogenous flip variables as exogenenous or exo det variables
1. the endogenous and exogenous flip variables are in the same order (not necessary to be contiguous but may help)
1. given the indices vector of flip variablesm implicit pairs of endogenous/exogenous variables are formed
1. If the observation of an endogenous variable is a NaN, the endogenous variables plays it usual role of endogenous variable
1. If the observation of an endogenous variables is a valid number, the endogenous variable is treated as exogenous and the corresponding flip exogenous variables is treated as endogenous
1. The presence of a NaN for an endogenous variable not declared as a flip variable is an error
1. The corner case of unconditional forecast should be accepted for ease of use
1. The solution is written back in ``y`` and ``x`` irrespective of the actual role of a variable in a given period
### Operations
``general_solver`` dispatches la résolution du nouveau problème selon
1. purely backward linear model
1. purely backward nonlinear model
1. purely forward linear model (if we have the algorithm...)
1. purely forward nonlinear model
1. general linear model
1. general nonlinear model
1. bytecode and or block model
and according to the options selecting a particular algorithmModel inversion and deterministic conditional forecast solve the same mathematical problem: solving a (non-)linear system where the identity of the unknown variables change from period to period. I suggest to create a unique function that would solve such problems.
``general_solver`` would take at least the following arguments:
* y: endogenous variables (matrix)
* x: exogenous variables (matrix) [possible concatenation of exo_det variables to the right]
* model: model (function handle)
* i_endo_flip: flip variables indices in endogenous variables (vector)
* i_exo_flip: flip variables indices in exogenous variables (vector)
### Conventions
1. there are as many endogenous flip variables as exogenenous or exo det variables
1. the endogenous and exogenous flip variables are in the same order (not necessary to be contiguous but may help)
1. given the indices vector of flip variablesm implicit pairs of endogenous/exogenous variables are formed
1. If the observation of an endogenous variable is a NaN, the endogenous variables plays it usual role of endogenous variable
1. If the observation of an endogenous variables is a valid number, the endogenous variable is treated as exogenous and the corresponding flip exogenous variables is treated as endogenous
1. The presence of a NaN for an endogenous variable not declared as a flip variable is an error
1. The corner case of unconditional forecast should be accepted for ease of use
1. The solution is written back in ``y`` and ``x`` irrespective of the actual role of a variable in a given period
### Operations
``general_solver`` dispatches la résolution du nouveau problème selon
1. purely backward linear model
1. purely backward nonlinear model
1. purely forward linear model (if we have the algorithm...)
1. purely forward nonlinear model
1. general linear model
1. general nonlinear model
1. bytecode and or block model
and according to the options selecting a particular algorithm4.7https://git.dynare.org/Dynare/dynare/-/issues/1702det_cond_forecast() argument checking is broken2020-02-11T09:44:04ZMichelJuillarddet_cond_forecast() argument checking is brokenIf one calls det_cond_forecast with two arguments only as in the manual example, the function fails with error
```
impossible case
```
that is triggered near line 208If one calls det_cond_forecast with two arguments only as in the manual example, the function fails with error
```
impossible case
```
that is triggered near line 2084.7MichelJuillardMichelJuillardhttps://git.dynare.org/Dynare/dynare/-/issues/1703det_cond_forecast() depends on oo_.dr.state_var but this is not always available2020-02-11T10:08:29ZMichelJuillarddet_cond_forecast() depends on oo_.dr.state_var but this is not always available``det_cond_forecast()`` depends on ``oo_.dr.state_var`` but this variable is computed by ``dyn_first_order_solver``. So it isn't available for a purely backward or purely forward model``det_cond_forecast()`` depends on ``oo_.dr.state_var`` but this variable is computed by ``dyn_first_order_solver``. So it isn't available for a purely backward or purely forward model4.7MichelJuillardMichelJuillardhttps://git.dynare.org/Dynare/dynare/-/issues/1704Update partial information code2020-03-02T16:14:50ZSébastien VillemotUpdate partial information codeFirst version located in https://git.dynare.org/Yang/dynareFirst version located in https://git.dynare.org/Yang/dynare4.7Sébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/1707Macro commands that take no arguments have spurious parentheses appended to t...2020-05-07T17:43:51ZSé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.4.7https://git.dynare.org/Dynare/dynare/-/issues/1709Automatic detrending2020-03-06T17:35:41ZFerhatMihoubiAutomatic detrendingFor the moment the deterministic or stochastic trends have to be declared using the trend_var (or log_trend_var) commands and the option deflator (or log_deflator) in var command to declare the trended variables.
The purpose of the new feature is to find and remove automatically the trends. To do so, the proposal is to add :
- an option in var command to indicate if the variable is expressed in logarithm or not (the default being not in logarithm). For instance *var(log) list of variables*.
- a command that will add to all endogenous variables a growth factor (additive or multiplicative depending on the previously declared status) and the equations that put in relation all the growth factors to theirs endogenous variables. This step should be performed in the preprocessor to produce a new dynamic model containing all the endogenous variables and the growth factor associated to all the endogenous variables.
- during the execution the complete new dynamic model should be solved to compute the growth factors and the steady state values of the endogenous variables.
This command could be *detrend* for instance.For the moment the deterministic or stochastic trends have to be declared using the trend_var (or log_trend_var) commands and the option deflator (or log_deflator) in var command to declare the trended variables.
The purpose of the new feature is to find and remove automatically the trends. To do so, the proposal is to add :
- an option in var command to indicate if the variable is expressed in logarithm or not (the default being not in logarithm). For instance *var(log) list of variables*.
- a command that will add to all endogenous variables a growth factor (additive or multiplicative depending on the previously declared status) and the equations that put in relation all the growth factors to theirs endogenous variables. This step should be performed in the preprocessor to produce a new dynamic model containing all the endogenous variables and the growth factor associated to all the endogenous variables.
- during the execution the complete new dynamic model should be solved to compute the growth factors and the steady state values of the endogenous variables.
This command could be *detrend* for instance.https://git.dynare.org/Dynare/dynare/-/issues/1715Clean root folder of /tests2020-03-07T17:21:34ZJohannes Pfeifer Clean root folder of /testsAll integration tests should be in subfolders. The current structure is a messAll integration tests should be in subfolders. The current structure is a mess4.7https://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/1718Auxillary particle filter --- number_of_state_variables is undefined2020-03-30T10:09:49ZArtur ZmanovskiiAuxillary particle filter --- number_of_state_variables is undefinedIn `particles/src/auxiliary_particle_filter.m` under specific options (`options_.particle.pruning=1`, `resampling` in `estimation()` is `systematic/generic`), a chunk of code is executed (lines 136--139), which has undefined variable (`number_of_state_variables` --- at lines 137--138) and causes error.In `particles/src/auxiliary_particle_filter.m` under specific options (`options_.particle.pruning=1`, `resampling` in `estimation()` is `systematic/generic`), a chunk of code is executed (lines 136--139), which has undefined variable (`number_of_state_variables` --- at lines 137--138) and causes error.4.7Stéphane Adjemianstepan@adjemian.euStéphane Adjemianstepan@adjemian.euhttps://git.dynare.org/Dynare/dynare/-/issues/1721Get rid of oo_.dr.kstate2020-05-04T16:22:55ZSébastien VillemotGet rid of oo_.dr.kstateIn particular, see the discussion in #1653In particular, see the discussion in #16534.7https://git.dynare.org/Dynare/dynare/-/issues/1725Better interface for mfs option2020-05-20T10:14:37ZSébastien VillemotBetter interface for mfs optionThe `mfs` option of the `model` keyword, that enables an additional optimization in the block decomposition, has an unfriendly interface. It currently accepts an integer, while it would be more natural to use keywords (the challenge is to choose keywords that reflect the natural ordering of the possible values).
The old integer values would still have to be kept for backward compatibility.
From an implementation point of view, the different values should be stored as an enum class in the preprocessor.The `mfs` option of the `model` keyword, that enables an additional optimization in the block decomposition, has an unfriendly interface. It currently accepts an integer, while it would be more natural to use keywords (the challenge is to choose keywords that reflect the natural ordering of the possible values).
The old integer values would still have to be kept for backward compatibility.
From an implementation point of view, the different values should be stored as an enum class in the preprocessor.4.7Sébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/1726Option mfs=3 gives wrong result2020-10-16T14:55:30ZSébastien VillemotOption mfs=3 gives wrong resultThe `mfs=3` option of the `model` keyword gives wrong results.
This can for example be verified by adding `mfs=3` to `deterministic/lola_solve_one_boundary.mod`.
Once this is fixed, we should add tests that check that all the possible values of `mfs` give the same result on a given model.
The option `mfs` is also broken in version 4.6.1. Several other problems with `mfs` have already be fixed in the 4.6 branch, but the present issue is still unfixed.The `mfs=3` option of the `model` keyword gives wrong results.
This can for example be verified by adding `mfs=3` to `deterministic/lola_solve_one_boundary.mod`.
Once this is fixed, we should add tests that check that all the possible values of `mfs` give the same result on a given model.
The option `mfs` is also broken in version 4.6.1. Several other problems with `mfs` have already be fixed in the 4.6 branch, but the present issue is still unfixed.4.7Sébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/1728Improvements to make install rule2020-07-28T08:34:19ZSébastien VillemotImprovements to make install ruleCurrently the preprocessor is installed at two places: `${prefix}/lib/dynare/matlab/preprocessorNN/` and `${prefix}/bin`. The former should probably be made a symlink to the latter.
By the way, we could rename the preprocessor binary to a better name.
Moreover, docs should be installed under `${prefix}/share/doc/dynare/`.Currently the preprocessor is installed at two places: `${prefix}/lib/dynare/matlab/preprocessorNN/` and `${prefix}/bin`. The former should probably be made a symlink to the latter.
By the way, we could rename the preprocessor binary to a better name.
Moreover, docs should be installed under `${prefix}/share/doc/dynare/`.4.7Sébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/1730Consider saving results using -v7.3 flag2020-06-15T10:29:17ZJohannes Pfeifer Consider saving results using -v7.3 flagWe may want to consider saving the results of a Dynare run using the `-v7.3` flag, which available after Matlab R2006b. That would help getting around occasional issues with the 2GB file limit otherwise present.We may want to consider saving the results of a Dynare run using the `-v7.3` flag, which available after Matlab R2006b. That would help getting around occasional issues with the 2GB file limit otherwise present.https://git.dynare.org/Dynare/dynare/-/issues/1731Error in derivatives of perfect foresight models with leaded or lagged exogen...2020-09-04T14:09:13ZMichelJuillardError in derivatives of perfect foresight models with leaded or lagged exogenous variablesA perfect foresight model with leads and lags in exogenous variables produces wrong derivative file ``dynamic_g1.m`` such as:
```
...
g1 = zeros(6, 12);
g1(1,8)=(-params(1));
g1(1,8)=1;
...
```
Here is ``test_0.mod``:
[test_o.mod](/uploads/27569e4244c8152ea98b9f1b7b48c21c/test_o.mod)
The issue occurs in 4.6 and in the unstable version.A perfect foresight model with leads and lags in exogenous variables produces wrong derivative file ``dynamic_g1.m`` such as:
```
...
g1 = zeros(6, 12);
g1(1,8)=(-params(1));
g1(1,8)=1;
...
```
Here is ``test_0.mod``:
[test_o.mod](/uploads/27569e4244c8152ea98b9f1b7b48c21c/test_o.mod)
The issue occurs in 4.6 and in the unstable version.4.7Sébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/1732Improve debugging options for perfect foresight2020-06-10T06:15:36ZJohannes Pfeifer Improve debugging options for perfect foresightWe occasionally have issues with singular Jacobians as in https://forum.dynare.org/t/blanchard-conditions-in-stochastic-and-deterministic-models/15980
It would be good to have a debugging options that would point to the culprit for e.g. a row or column of zeros. Maybe we could add this to `model_diagnostics`.
[ADS_NE.mod](/uploads/93a8991fbd2cfd3eface2eb12d9a745f/ADS_NE.mod)We occasionally have issues with singular Jacobians as in https://forum.dynare.org/t/blanchard-conditions-in-stochastic-and-deterministic-models/15980
It would be good to have a debugging options that would point to the culprit for e.g. a row or column of zeros. Maybe we could add this to `model_diagnostics`.
[ADS_NE.mod](/uploads/93a8991fbd2cfd3eface2eb12d9a745f/ADS_NE.mod)https://git.dynare.org/Dynare/dynare/-/issues/1734Finish nonlinear prior restrictions2020-06-22T10:25:28ZJohannes Pfeifer Finish nonlinear prior restrictionsSee https://git.dynare.org/Dynare/dynare/-/commit/0efcef8f20c549c1484ce56c8986bc4c24d5292aSee https://git.dynare.org/Dynare/dynare/-/commit/0efcef8f20c549c1484ce56c8986bc4c24d5292a4.7https://git.dynare.org/Dynare/dynare/-/issues/1738Publication-quality plots2020-07-15T10:44:06ZWilli Mutschlerwilli@mutschler.euPublication-quality plotsMatlab's capabilities to produce plots are very low-level and I usually find that using e.g. R's ggplot2 function gives "better" looking figures. I recently came across the following project which basically ports ggplot2 to matlab and is under the MIT license:
https://github.com/piermorel/gramm
What do @all think, would it be good to use this and provide publication-quality plots in Dynare?Matlab's capabilities to produce plots are very low-level and I usually find that using e.g. R's ggplot2 function gives "better" looking figures. I recently came across the following project which basically ports ggplot2 to matlab and is under the MIT license:
https://github.com/piermorel/gramm
What do @all think, would it be good to use this and provide publication-quality plots in Dynare?https://git.dynare.org/Dynare/dynare/-/issues/1739Investigate parallel issues2020-07-13T14:00:20ZJohannes Pfeifer Investigate parallel issuesSee https://forum.dynare.org/t/parallel-estimation-mcmc-diagnostics-issue/16228/4See https://forum.dynare.org/t/parallel-estimation-mcmc-diagnostics-issue/16228/44.7https://git.dynare.org/Dynare/dynare/-/issues/1743Start diary earlier to include input arguments and Dynare version2020-09-21T10:32:05ZJohannes Pfeifer Start diary earlier to include input arguments and Dynare versionCurrently, the diary only starts after the version and the input arguments have been printed. That way, important information is missing when calling a mod-file with command-line switches.Currently, the diary only starts after the version and the input arguments have been printed. That way, important information is missing when calling a mod-file with command-line switches.4.7https://git.dynare.org/Dynare/dynare/-/issues/1744endogenous_prior with missing observation2020-09-21T10:32:53Znaivejendogenous_prior with missing observationHi dynare team,
(Sorry if I posted in the wrong place, I just realised that gitlab seems for developers only)
In v4.6.2, endogenous_prior cannot work with missing observation, but this is not pointed out in the Reference Manual.
I suppose a naive way to fix this is to exclude any period or variables with missing observations in the calculation of statistics.
Currently, I modified the code as follows but not sure if this is statistically correct. Is there a better way to make this work?
```matlab
Ydemean(:,j)=Y(:,j)-mean(Y(:,j),'omitnan');
Fhat=std(Ydemean,1,'omitnan').^2';
for j=1:n
Ydemean(:,j)=Y(:,j)-mean(Y(:,j),'omitnan');
end
Fhat=std(Ydemean,1,'omitnan').^2';%Fhat=diag(Ydemean'*Ydemean)/Tsamp;
Sgood=find(~any(isnan(Y),2));
Tgood=length(Sgood);
hmat=zeros(n,Tgood);
% we need ht, where t=1,...,T
for t=1:Tgood
hmat(:,t)=diag(Ydemean(Sgood(t),:)'*Ydemean(Sgood(t),:))-Fhat;
end
% To calculate Shat we need C0, C1 and C2
for t=1:Tgood
C0=C0+1/Tgood*hmat(:,t)*hmat(:,t)';
end
for t=2:Tgood
C1=C1+1/(Tgood-1)*hmat(:,t)*hmat(:,t-1)';
end
for t=3:Tgood
C2=C2+1/(Tgood-2)*hmat(:,t)*hmat(:,t-2)';
end
```Hi dynare team,
(Sorry if I posted in the wrong place, I just realised that gitlab seems for developers only)
In v4.6.2, endogenous_prior cannot work with missing observation, but this is not pointed out in the Reference Manual.
I suppose a naive way to fix this is to exclude any period or variables with missing observations in the calculation of statistics.
Currently, I modified the code as follows but not sure if this is statistically correct. Is there a better way to make this work?
```matlab
Ydemean(:,j)=Y(:,j)-mean(Y(:,j),'omitnan');
Fhat=std(Ydemean,1,'omitnan').^2';
for j=1:n
Ydemean(:,j)=Y(:,j)-mean(Y(:,j),'omitnan');
end
Fhat=std(Ydemean,1,'omitnan').^2';%Fhat=diag(Ydemean'*Ydemean)/Tsamp;
Sgood=find(~any(isnan(Y),2));
Tgood=length(Sgood);
hmat=zeros(n,Tgood);
% we need ht, where t=1,...,T
for t=1:Tgood
hmat(:,t)=diag(Ydemean(Sgood(t),:)'*Ydemean(Sgood(t),:))-Fhat;
end
% To calculate Shat we need C0, C1 and C2
for t=1:Tgood
C0=C0+1/Tgood*hmat(:,t)*hmat(:,t)';
end
for t=2:Tgood
C1=C1+1/(Tgood-1)*hmat(:,t)*hmat(:,t-1)';
end
for t=3:Tgood
C2=C2+1/(Tgood-2)*hmat(:,t)*hmat(:,t-2)';
end
```4.7https://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.7MichelJuillardMichelJuillardhttps://git.dynare.org/Dynare/dynare/-/issues/1746Create a MEX equivalent to minreal from the control toolbx2020-10-28T10:04:34ZSé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 Villemot