dynare issueshttps://git.dynare.org/Dynare/dynare/-/issues2021-11-24T10:32:33Zhttps://git.dynare.org/Dynare/dynare/-/issues/1823Fix or block interplay of stochastic Ramsey and block2021-11-24T10:32:33ZJohannes PfeiferFix or block interplay of stochastic Ramsey and block1. The attached file has a problem with the residual of the static model. It outputs residuals of the conditional steady state file that do not exist without `block` [rams1.mod](/uploads/708d194c770eb1cb8e1747f533139c19/rams1.mod)
2. Whe...1. The attached file has a problem with the residual of the static model. It outputs residuals of the conditional steady state file that do not exist without `block` [rams1.mod](/uploads/708d194c770eb1cb8e1747f533139c19/rams1.mod)
2. When overriding this and moving into `dyn_ramsey_static`, the `nblock`-input of the `+FNAME.static.m`-file is not set, suggesting that `block` is not supported in the first place.5.xSébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/1824Please add FreeBSD to the Download page on https://www.dynare.org2021-11-23T15:34:39Zyuri@FreeBSDPlease add FreeBSD to the Download page on https://www.dynare.org
Please add the dynare FreeBSD package to your [Download page](https://www.dynare.org/download/).
It should probably be in a separate page (```BSD```).
The link is [here](https://www.freshports.org/science/dynare/).
The text could say...
Please add the dynare FreeBSD package to your [Download page](https://www.dynare.org/download/).
It should probably be in a separate page (```BSD```).
The link is [here](https://www.freshports.org/science/dynare/).
The text could say that to install ```Dynare``` on ```FreeBSD``` please use the command: ```pkg install dynare```.
Thank you,
Yuri (the maintainer of the FreeBSD dynare port).Sébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/1338risky steady state: no interface, test suite2021-11-19T11:16:16ZHoutan Bastanirisky steady state: no interface, test suiteThere are several issues with risky steady state:
1. It has no interface. Why? Is this something we want to keep (hidden) in Dynare?
1. It the .mod files that use it are not in the test suite. Why?
There are several issues with risky steady state:
1. It has no interface. Why? Is this something we want to keep (hidden) in Dynare?
1. It the .mod files that use it are not in the test suite. Why?
5.xSébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/147Accuracy checks2021-11-19T11:16:08ZSébastien VillemotAccuracy checkshttps://git.dynare.org/Dynare/dynare/-/issues/1759Decide whether to drop Windows 7 support2021-11-16T16:29:57ZSé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...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.5.xSébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/978Fix interface/options for stochastic extended path in master2021-11-11T13:22:27ZJohannes PfeiferFix interface/options for stochastic extended path in masterNot all required options are set by default. For example, `rs2.mod` needs to manually set
```
options_.ep.IntegrationAlgorithm='UT_2p+1';
```
as otherwise a crash in `setup_integration_nodes.m` happens. We should properly initialize a...Not all required options are set by default. For example, `rs2.mod` needs to manually set
```
options_.ep.IntegrationAlgorithm='UT_2p+1';
```
as otherwise a crash in `setup_integration_nodes.m` happens. We should properly initialize all options and add a unit test that tests the default options.https://git.dynare.org/Dynare/dynare/-/issues/1788Equations for expectation variables in the .mod file of a model2021-11-10T09:58:39ZAnastasia ZhEquations for expectation variables in the .mod file of a modelAt this stage equations for the PV variables are created by `var_expectation(varexp)` or `pac_expectation(pacman)` which can be found then in the generated .inc files.
It is preferable to have them appear directly in the .mod file of t...At this stage equations for the PV variables are created by `var_expectation(varexp)` or `pac_expectation(pacman)` which can be found then in the generated .inc files.
It is preferable to have them appear directly in the .mod file of the model.
Here is one way of doing it. Say we cherrypick a pac equation from an estimation file. Then the generated simulation file used afterward to aggregate a big model shall automatically include an equation for expectation variable used in this pac equation.https://git.dynare.org/Dynare/dynare/-/issues/415Use of subexpression caching in Dynare++ evaluator can lead to wrong results2021-11-08T11:22:42ZSébastien VillemotUse of subexpression caching in Dynare++ evaluator can lead to wrong resultsConsider the following MOD file:
```
var y;
varexo e;
parameters beta rbar rebar lambdae t1 t2;
beta = 1/1.02^0.25;
rbar = 1.02^0.25;
rebar = (1.065-rbar^4+1)^0.25;
lambdae = 0.2;
lambdae = 1-lambdae;
t1 = (1-lambdae)/beta;
t2 = lamb...Consider the following MOD file:
```
var y;
varexo e;
parameters beta rbar rebar lambdae t1 t2;
beta = 1/1.02^0.25;
rbar = 1.02^0.25;
rebar = (1.065-rbar^4+1)^0.25;
lambdae = 0.2;
lambdae = 1-lambdae;
t1 = (1-lambdae)/beta;
t2 = lambdae/beta;
model;
y = t2*y(-1)+e;
end;
initval;
y = 0;
end;
vcov = [1];
order = 1;
```
The value computed for `t1` will be wrong, and will be equal to that of `t2`. Here is what happens step-by-step:
- `lambdae = 0.2;` => Dynare++ registers that `lambdae=0.2`
- `lambdae=1-lambdae;` => Dynare++ computes `1-lambdae=0.8` **and caches that identity**; then it updates `lambdae=0.8`
- `t1 = (1-lambdae)/beta;` => Dynare++ (wrongly) uses the cached value `1-lambdae=0.8`
- `t2 = lambdae/beta;` => Dynare++ (rightly) uses the value `lambdae=0.8`
It seems that the only sensible solution to this problem is to disable subexpression caching during the evaluation phase.
4.4https://git.dynare.org/Dynare/dynare/-/issues/1822MacOS M1 compilation of manual: TypeError: 'DynareLexer' object is not callable2021-10-24T11:19:23ZWilli Mutschlerwilli@mutschler.euMacOS M1 compilation of manual: TypeError: 'DynareLexer' object is not callableWhen I try to compile the manual on my M1 Macbook Air using Rosetta 2 (i.e. `arch -x86_64 make html` or `arch -x86_64 make pdf`), I get the following error: `TypeError: 'DynareLexer' object is not callable
`.
Here is the full traceback:...When I try to compile the manual on my M1 Macbook Air using Rosetta 2 (i.e. `arch -x86_64 make html` or `arch -x86_64 make pdf`), I get the following error: `TypeError: 'DynareLexer' object is not callable
`.
Here is the full traceback:
```
# Sphinx version: 4.2.0
# Python version: 3.10.0 (CPython)
# Docutils version: 0.17.1 release
# Jinja2 version: 3.0.1
# Last messages:
# looking for now-outdated files...
# none found
# pickling environment...
# done
# checking consistency...
# done
# preparing documents...
# done
# writing output... [ 9%] bibliography
# writing output... [ 18%] dynare-misc-commands
# Loaded extensions:
# sphinx.ext.mathjax (4.2.0) from /usr/local/Cellar/sphinx-doc/4.2.0_1/libexec/lib/python3.10/site-packages/sphinx/ext/mathjax.py
# sphinxcontrib.applehelp (1.0.2) from /usr/local/Cellar/sphinx-doc/4.2.0_1/libexec/lib/python3.10/site-packages/sphinxcontrib/applehelp/__init__.py
# sphinxcontrib.devhelp (1.0.2) from /usr/local/Cellar/sphinx-doc/4.2.0_1/libexec/lib/python3.10/site-packages/sphinxcontrib/devhelp/__init__.py
# sphinxcontrib.htmlhelp (2.0.0) from /usr/local/Cellar/sphinx-doc/4.2.0_1/libexec/lib/python3.10/site-packages/sphinxcontrib/htmlhelp/__init__.py
# sphinxcontrib.serializinghtml (1.1.5) from /usr/local/Cellar/sphinx-doc/4.2.0_1/libexec/lib/python3.10/site-packages/sphinxcontrib/serializinghtml/__init__.py
# sphinxcontrib.qthelp (1.0.3) from /usr/local/Cellar/sphinx-doc/4.2.0_1/libexec/lib/python3.10/site-packages/sphinxcontrib/qthelp/__init__.py
# alabaster (0.7.12) from /usr/local/Cellar/sphinx-doc/4.2.0_1/libexec/lib/python3.10/site-packages/alabaster/__init__.py
# sphinx.ext.autodoc.preserve_defaults (1.0) from /usr/local/Cellar/sphinx-doc/4.2.0_1/libexec/lib/python3.10/site-packages/sphinx/ext/autodoc/preserve_defaults.py
# sphinx.ext.autodoc.type_comment (4.2.0) from /usr/local/Cellar/sphinx-doc/4.2.0_1/libexec/lib/python3.10/site-packages/sphinx/ext/autodoc/type_comment.py
# sphinx.ext.autodoc (4.2.0) from /usr/local/Cellar/sphinx-doc/4.2.0_1/libexec/lib/python3.10/site-packages/sphinx/ext/autodoc/__init__.py
Traceback (most recent call last):
File "/usr/local/Cellar/sphinx-doc/4.2.0_1/libexec/lib/python3.10/site-packages/sphinx/cmd/build.py", line 280, in build_main
app.build(args.force_all, filenames)
File "/usr/local/Cellar/sphinx-doc/4.2.0_1/libexec/lib/python3.10/site-packages/sphinx/application.py", line 343, in build
self.builder.build_update()
File "/usr/local/Cellar/sphinx-doc/4.2.0_1/libexec/lib/python3.10/site-packages/sphinx/builders/__init__.py", line 293, in build_update
self.build(to_build,
File "/usr/local/Cellar/sphinx-doc/4.2.0_1/libexec/lib/python3.10/site-packages/sphinx/builders/__init__.py", line 357, in build
self.write(docnames, list(updated_docnames), method)
File "/usr/local/Cellar/sphinx-doc/4.2.0_1/libexec/lib/python3.10/site-packages/sphinx/builders/__init__.py", line 531, in write
self._write_serial(sorted(docnames))
File "/usr/local/Cellar/sphinx-doc/4.2.0_1/libexec/lib/python3.10/site-packages/sphinx/builders/__init__.py", line 541, in _write_serial
self.write_doc(docname, doctree)
File "/usr/local/Cellar/sphinx-doc/4.2.0_1/libexec/lib/python3.10/site-packages/sphinx/builders/html/__init__.py", line 626, in write_doc
self.docwriter.write(doctree, destination)
File "/usr/local/Cellar/sphinx-doc/4.2.0_1/libexec/lib/python3.10/site-packages/docutils/writers/__init__.py", line 78, in write
self.translate()
File "/usr/local/Cellar/sphinx-doc/4.2.0_1/libexec/lib/python3.10/site-packages/sphinx/writers/html.py", line 70, in translate
self.document.walkabout(visitor)
File "/usr/local/Cellar/sphinx-doc/4.2.0_1/libexec/lib/python3.10/site-packages/docutils/nodes.py", line 227, in walkabout
if child.walkabout(visitor):
File "/usr/local/Cellar/sphinx-doc/4.2.0_1/libexec/lib/python3.10/site-packages/docutils/nodes.py", line 227, in walkabout
if child.walkabout(visitor):
File "/usr/local/Cellar/sphinx-doc/4.2.0_1/libexec/lib/python3.10/site-packages/docutils/nodes.py", line 227, in walkabout
if child.walkabout(visitor):
[Previous line repeated 3 more times]
File "/usr/local/Cellar/sphinx-doc/4.2.0_1/libexec/lib/python3.10/site-packages/docutils/nodes.py", line 219, in walkabout
visitor.dispatch_visit(self)
File "/usr/local/Cellar/sphinx-doc/4.2.0_1/libexec/lib/python3.10/site-packages/sphinx/util/docutils.py", line 477, in dispatch_visit
method(node)
File "/usr/local/Cellar/sphinx-doc/4.2.0_1/libexec/lib/python3.10/site-packages/sphinx/writers/html5.py", line 417, in visit_literal_block
highlighted = self.highlighter.highlight_block(
File "/usr/local/Cellar/sphinx-doc/4.2.0_1/libexec/lib/python3.10/site-packages/sphinx/highlighting.py", line 149, in highlight_block
lexer = self.get_lexer(source, lang, opts, force, location)
File "/usr/local/Cellar/sphinx-doc/4.2.0_1/libexec/lib/python3.10/site-packages/sphinx/highlighting.py", line 127, in get_lexer
lexer = lexer_classes[lang](**opts)
TypeError: 'DynareLexer' object is not callable
```https://git.dynare.org/Dynare/dynare/-/issues/1820Invalid memory accesses in local_state_space_iteration_2 when there are more ...2021-10-21T18:11:05ZSébastien VillemotInvalid memory accesses in local_state_space_iteration_2 when there are more shocks than statesIn [local_state_space_iteration_2](mex/sources/local_state_space_iterations/local_state_space_iteration_2.cc#L166), in function `ss2Iteration`, the block that computes `ghx·yhat+ghu·u` reads as follows:
```
for (int column = 0,...In [local_state_space_iteration_2](mex/sources/local_state_space_iterations/local_state_space_iteration_2.cc#L166), in function `ss2Iteration`, the block that computes `ghx·yhat+ghu·u` reads as follows:
```
for (int column = 0, column_ = 0; column < q; column++, column_ += m)
{
int i1 = variable+column_;
int i2 = column+particle__;
int i3 = column+particle___;
y[variable_] += ghx[i1]*yhat[i2];
y[variable_] += ghu[i1]*epsilon[i3];
}
for (int column = q, column_ = q*m; column < n; column++, column_ += m)
y[variable_] += ghx[variable+column_]*yhat[column+particle__];
```
This code makes the implicit assumption that `q⩽n`, i.e. that the number of shocks is less than or equal to the number of states. If `q>n`, it will try to read invalid memory references in `ghx` and `yhat`, and it will either crash or return dummy results.
The same problem is present in the `ss2Iteration_pruning` function.
The fix is simply to reorganize the loops, with one loop that only deals with the states and another one that deals with shocks.
@stepan-a If you agree with this diagnostic, I will take care of fixing it.5.xSébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/1821evaluate_planner_objective does not compute expected utility correctly2021-10-18T16:43:48ZJohannes Pfeiferevaluate_planner_objective does not compute expected utility correctlySee the failed tests in !1945
The proximate cause is that the expected value `EU` in `evaluate_planner_objective.m` differs from what you would get when it were part of the variables in `oo_.mean`.See the failed tests in !1945
The proximate cause is that the expected value `EU` in `evaluate_planner_objective.m` differs from what you would get when it were part of the variables in `oo_.mean`.5.xhttps://git.dynare.org/Dynare/dynare/-/issues/1819Fix bug in mex k-order-simulations (i.e. without pruning)2021-10-12T15:39:39ZJohannes PfeiferFix bug in mex k-order-simulations (i.e. without pruning)The mex-file `dynare_simul_` erroneously iterates on the policy function with a zero shock vector for the first (non-endogenous) period. As a consequence, results differ from the m-file-based simulations at second order and from a one at...The mex-file `dynare_simul_` erroneously iterates on the policy function with a zero shock vector for the first (non-endogenous) period. As a consequence, results differ from the m-file-based simulations at second order and from a one at a time sequential simulation (see https://forum.dynare.org/t/simult-results-different-with-loop/19053/3).
The bug will not affect
1. third order simulations with pruning, which are based on the m-file.
2. IRFs starting the stochastic steady state/ergodic mean in the absence of shocks due to it being the fixed point of the simulation.
The bug will typically hardly affect moment computations and IRFs at the ergodic mean due to the initial burn-in period. In that case, the initial condition should wash out.5.xhttps://git.dynare.org/Dynare/dynare/-/issues/1663datafile option in perfect_foresight_setup: incomplete documentation and not ...2021-09-23T15:10:09ZMichelJuillarddatafile option in perfect_foresight_setup: incomplete documentation and not flexible enoughthe datafile option in perfect_foresight solver requires a text file without variable names, variables being order in order of VAR statement. The file name must end with ``_endo.dat``.
- [x] make loading data for guess value more flex...the datafile option in perfect_foresight solver requires a text file without variable names, variables being order in order of VAR statement. The file name must end with ``_endo.dat``.
- [x] make loading data for guess value more flexible
- [x] honor INITVAL_FILE command or deprecate it
- [ ] make possible to use guess values with simul_backward-modelhttps://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/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/617Fix translation of histval to one-lag problem2021-09-22T07:54:31ZJohannes PfeiferFix translation of histval to one-lag problemFor deterministic simulations with more than one lag, the translation to a problem with one lag for use in `sim1` does not work.
The mod-file
```
var c k z_forward z_backward;
varexo x z_shock;
parameters alph gam delt bet aa;
alph=0...For deterministic simulations with more than one lag, the translation to a problem with one lag for use in `sim1` does not work.
The mod-file
```
var c k z_forward z_backward;
varexo x z_shock;
parameters alph gam delt bet aa;
alph=0.5;
gam=0.5;
delt=0.02;
bet=0.05;
aa=0.5;
model;
c + k - aa*x*k(-1)^alph - (1-delt)*k(-1); // Resource constraint
c^(-gam) - (1+bet)^(-1)*(aa*alph*x(+1)*k^(alph-1) + 1 - delt)*c(+1)^(-gam); // Euler equation
z_backward=0.1*1+0.3*z_backward(-1)+0.3*z_backward(-2)+0.3*z_backward(-3)+(x(-4)-1);
z_forward=0.1*1+0.45*z_forward(+1)+0.45*z_forward(+2)+(x(+4)-1);
end;
initval;
c = 1.2;
k = 12;
x = 1;
end;
histval;
x(-1)=1.30;
x(-2)=1.30;
end;
shocks;
var x;
periods 2;
values 0.9;
end;
simul(periods=200,maxit=100);
```
shows that the problem comes from `M_.endo_histval`, which is set to
```
M_.endo_histval = zeros(M_.endo_nbr,M_.maximum_lag);
oo_.exo_simul( M_.maximum_lag + -2, 1 ) = 1.30;
oo_.exo_simul( M_.maximum_lag + -1, 1 ) = 1.30;
```
and thus has more than one initial period.
4.5https://git.dynare.org/Dynare/dynare/-/issues/1671Refactoring initval_file and histval_file2021-09-22T07:54:31ZMichelJuillardRefactoring initval_file and histval_file``initval_file`` and ``histvfal_file`` should be more flexible and have functionalities similar to option ``datafile``in ``estimation``
# Usage
## initval_file
- is used only in perfect foresight
- provides a guess value for computin...``initval_file`` and ``histvfal_file`` should be more flexible and have functionalities similar to option ``datafile``in ``estimation``
# Usage
## initval_file
- is used only in perfect foresight
- provides a guess value for computing the solution
- in absence of ``histval`` or ``histval_file`` provides the initial conditions for the simulation (we don't want to require users to upload two files for initial conditions and guess values
## histval_file
- is used for stochastic and perfect foresight models
- provides initial conditions
# Current implementation
## initval_file
- accept ``.m``, ``.mat``, ``.xls(x)``, ``.csv`` files
- modifies directly ``oo_.endo_simul``, ``oo_.exo_simul``, but not ``oo_.exo_det_simul``
## histval_file
- accept only files prepared by ``smoother2histval`` that uses odd format
- modifies directly ``oo_.endo_simul``, ``oo_.exo_simul``, but not ``oo_.exo_det_simul``
- note that ``histval`` sets a ``dseries`` object
# Proposal
1. have the same interface for ``initval_file`` and ``histval_file``
2. add an option ``dseries`` to be able to pass a ``dseries`` object
3. handle references to ``varexo_det`` variables
4. use the ``dseries`` interface to read files
5. ``initval_file`` and ``histval_file```set ``dseries`` object
6. modify ``make_y_`` ``make_ex_`` accordingly
7. handle auxiliary variables in a consistent manner (see #1004)
# Breaking changes
1. Documented behavior of ``initval_file``: None
2. Documented behavior of ``histval_file``: None
3. Documented behavior of ``perfect_foresight_setup``: the format of files designated in option ``filename`` has changed
4. Function ``initvalf.m``
* ``M_`` and ``options`` are added to inputs
* the old ``filename`` input triggers an error
* function ``initvalf()`` sets a result ``dseries`` on output
5. Function ``histvalf.m``
* ``M_`` and ``options`` are added to inputs
* the old ``filename`` input triggers an error
* function ``histvalf()`` sets a result ``dseries`` on output
* ``histvalf.m``doesn't recognize the old ``smoother2histval`` file format anymore.
6. Function ``smoother2histval.m``
* when an output file is requested ``smoother2histval()`` creates a ``.mat`` file containing a single ``dseries``
* ``smoother2histval.m`` saves now M_.orig_maximum_lag`` observations instead of ``oo_.maximum_lag`` in order to be able to recompute auxiliary variables
* It will not be possible to use a file saved with an previous version of ``smoother2histval``
# Questions
1. Is it a problem to have an optional ``dseries`` input in an instruction called ``initval_file`` and no file strictly speaking of?
WORK IN PROGRESS5.xMichelJuillardMichelJuillardhttps://git.dynare.org/Dynare/dynare/-/issues/1817Find workaround for warnings at Dynare startup under Octave2021-09-21T16:43:54ZSébastien VillemotFind workaround for warnings at Dynare startup under OctaveWhen Dynare starts under Octave, one gets:
```
warning: function /home/sebastien/dynare/unstable/matlab/+pac/+bgp/get.m shadows a built-in function
warning: called from
dynun at line 4 column 5
warning: function /home/sebastien/dyna...When Dynare starts under Octave, one gets:
```
warning: function /home/sebastien/dynare/unstable/matlab/+pac/+bgp/get.m shadows a built-in function
warning: called from
dynun at line 4 column 5
warning: function /home/sebastien/dynare/unstable/matlab/+pac/+bgp/set.m shadows a built-in function
warning: called from
dynun at line 4 column 5
```
This is the consequence of an [Octave bug](https://savannah.gnu.org/bugs/?46849).
A partial workaround was implemented in 4c0b2e8c4ec2df8f1833769db1c873486d2b87f7, but it does not suppress early warnings.
A better solution should be found.5.xSébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/1749Fix testsuite for Octave2021-09-21T15:58:35ZWilli 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:
- [x] analytic_derivatives/BrockMirman_PertParamsDerivs (on RHEL...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:
- [x] 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)5.xSébastien VillemotSébastien Villemothttps://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.x