dynare issueshttps://git.dynare.org/Dynare/dynare/-/issues2020-05-26T15:05:02Zhttps://git.dynare.org/Dynare/dynare/-/issues/1727Blocks of type "evaluate backward" are not correctly simulated2020-05-26T15:05:02ZSébastien VillemotBlocks of type "evaluate backward" are not correctly simulatedThe testsuite does not currently have a block of this type (which typically appears when there is a purely forward variable).
Tasks:
- [x] Fix the bug in MATLAB mode
- [ ] Fix the bug in bytecode
- [ ] Add a test in the testsuite
The test can simply consist of adding an equation to `block_bytecode/ls2003.mod`, which would read as: `pure_forward = 0.9*pure_forward(+1) + e_pure_forward;`. The `e_pure_forward` variable needs to be shocked, preferably in the end of the simulation sample.The testsuite does not currently have a block of this type (which typically appears when there is a purely forward variable).
Tasks:
- [x] Fix the bug in MATLAB mode
- [ ] Fix the bug in bytecode
- [ ] Add a test in the testsuite
The test can simply consist of adding an equation to `block_bytecode/ls2003.mod`, which would read as: `pure_forward = 0.9*pure_forward(+1) + e_pure_forward;`. The `e_pure_forward` variable needs to be shocked, preferably in the end of the simulation sample.4.7Sébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/1726Option mfs=3 gives wrong result2020-05-20T10:26:56ZSé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/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/1724Method of Moments in Dynare (GMM, SMM, IRF Matching)2020-05-28T06:11:04ZWilli Mutschlerwilli@mutschler.euMethod of Moments in Dynare (GMM, SMM, IRF Matching)Hey,
I am working on a first draft for a toolbox for moment estimation with GMM, SMM and IRF-Matching (I will start with GMM, then SMM, and deal with IRF-matching later) which will work for perturbation (with pruning) up to third-order. I have a couple of questions|proposal for the best interface and call for this and would like your guys take on this.
### Declaring parameters
Here I would simply opt to what we do in a Maximum likelihood estimation and use the same syntax in an `estimated_params` or an `estimated_params_bounds` block:
```
stderr VARIABLE_NAME | corr VARIABLE_NAME_1, VARIABLE_NAME_2 | PARAMETER_NAME, LOWER_BOUND, UPPER_BOUND;
```
### Declaring which moments to use
Here I would propose a block similar to `moment_calibration`, but call it `estimated_moments`:
```
estimated_moments;
y_obs,y_obs; //[unconditional variance]
y_obs,y_obs(-(1:4)); //[some acf]
@#for ilag in -2:2
y_obs,R_obs(@{ilag}); //[ccf]
@#endfor
end;
```
### Invocation
Now the toughest question. How to invoke it? I see two options.
Option A: Add an option to `estimation`, e.g.
```
estimation(moments_estimation='GMM');
```
Option B: Have an own command for this, e.g.:
```
gmm_estimation(OPTIONS);
smm_estimation(OPTIONS);
irf_matching(OPTIONS);
```
which then internally calls a wrapper `dynare_moments_estimation.m` and runs the toolbox.
What do you guys think?Hey,
I am working on a first draft for a toolbox for moment estimation with GMM, SMM and IRF-Matching (I will start with GMM, then SMM, and deal with IRF-matching later) which will work for perturbation (with pruning) up to third-order. I have a couple of questions|proposal for the best interface and call for this and would like your guys take on this.
### Declaring parameters
Here I would simply opt to what we do in a Maximum likelihood estimation and use the same syntax in an `estimated_params` or an `estimated_params_bounds` block:
```
stderr VARIABLE_NAME | corr VARIABLE_NAME_1, VARIABLE_NAME_2 | PARAMETER_NAME, LOWER_BOUND, UPPER_BOUND;
```
### Declaring which moments to use
Here I would propose a block similar to `moment_calibration`, but call it `estimated_moments`:
```
estimated_moments;
y_obs,y_obs; //[unconditional variance]
y_obs,y_obs(-(1:4)); //[some acf]
@#for ilag in -2:2
y_obs,R_obs(@{ilag}); //[ccf]
@#endfor
end;
```
### Invocation
Now the toughest question. How to invoke it? I see two options.
Option A: Add an option to `estimation`, e.g.
```
estimation(moments_estimation='GMM');
```
Option B: Have an own command for this, e.g.:
```
gmm_estimation(OPTIONS);
smm_estimation(OPTIONS);
irf_matching(OPTIONS);
```
which then internally calls a wrapper `dynare_moments_estimation.m` and runs the toolbox.
What do you guys think?4.7https://git.dynare.org/Dynare/dynare/-/issues/1723Equations defining model local variables are not included in generated JSON f...2020-05-12T14:19:03ZTom HoldenEquations defining model local variables are not included in generated JSON filesThis bug came up in conversation with @MichelJuillard .
For example, this model block:
```
model;
#Pi=exp(pi);
#Pi_LEAD=exp(pi(1));
#Pi_STEADY=exp(pi_STEADY);
#kappa=(gamma/2)*(Pi-1)^2;
#kappa_STEADY=(gamma/2)*(Pi_STEADY-1)^2;
#c=log(1-kappa-eta)+y;
#c_LEAD=log(1-(gamma/2)*(Pi_LEAD-1)^2-eta)+y(1);
#h=y-z;
#w=sigma*c+nu*h-log(1-tauw);
#re=-log(beta)-d(1)+pi_STEADY;
#y_STEADY=(1/(sigma+nu))*(log((1-tauw)*((1-beta)*(Pi_STEADY-1)*Pi_STEADY/theta*gamma+1))-sigma*log(1-kappa_STEADY-eta));
#gdp=log(1-kappa)+y;
#gdp_STEADY=log(1-kappa_STEADY)+y_STEADY;
#dynareOBCMaxArgA1=(0);
#dynareOBCMaxArgB1=(re+phi_pi*(pi-pi_STEADY)+phi_y*(gdp-gdp_STEADY));
#dynareOBCMaxFunc1=max(dynareOBCMaxArgA1,dynareOBCMaxArgB1);
r=(dynareOBCMaxFunc1);
1=beta*exp(d(1)+r-pi(1)+sigma*(c-c_LEAD));
(Pi-1)*Pi=theta/gamma*(exp(w-z)-1)+beta*exp(d(1)+sigma*(c-c_LEAD)+y(1)-y)*(Pi_LEAD-1)*Pi_LEAD;
d=rhod*d(-1)+sigmad*epsilond;
z=rhoz*z(-1)+sigmaz*epsilonz;
end;
```
becomes this in the JSON file (with `json=parse`):
```
...
"model":[
{"lhs": "r", "rhs": "dynareOBCMaxFunc1", "line": 37}
, {"lhs": "1", "rhs": "beta*exp(d(1)+r-pi(1)+sigma*(c-c_LEAD))", "line": 38}
, {"lhs": "Pi*(Pi-1)", "rhs": "theta/gamma*(exp(w-z)-1)+Pi_LEAD*(Pi_LEAD-1)*beta*exp(y(1)+d(1)+sigma*(c-c_LEAD)-y)", "line": 39}
, {"lhs": "d", "rhs": "rhod*d(-1)+sigmad*epsilond", "line": 40}
, {"lhs": "z", "rhs": "rhoz*z(-1)+sigmaz*epsilonz", "line": 41}
]
, "xrefs": {"parameters": [], "endogenous": [], "exogenous": [], "exogenous_deterministic": []}
, "abstract_syntax_tree":[
{ "number":0, "line":37, "AST": {"node_type" : "BinaryOpNode", "op" : "=", "arg1" : {"node_type" : "VariableNode", "name" : "r", "type" : "endogenous", "lag" : 0}, "arg2" : {"node_type" : "VariableNode", "name" : "dynareOBCMaxFunc1", "type" : "modelLocalVariable", "lag" : 0}}}, { "number":1, "line":38, "AST": {"node_type" : "BinaryOpNode", "op" : "=", "arg1" : {"node_type" : "NumConstNode", "value" : 1}, "arg2" : {"node_type" : "BinaryOpNode", "op" : "*", "arg1" : {"node_type" : "VariableNode", "name" : "beta", "type" : "parameter", "lag" : 0}, "arg2" : {"node_type" : "UnaryOpNode", "op" : "exp", "arg" : {"node_type" : "BinaryOpNode", "op" : "+", "arg1" : {"node_type" : "BinaryOpNode", "op" : "-", "arg1" : {"node_type" : "BinaryOpNode", "op" : "+", "arg1" : {"node_type" : "VariableNode", "name" : "d", "type" : "endogenous", "lag" : 1}, "arg2" : {"node_type" : "VariableNode", "name" : "r", "type" : "endogenous", "lag" : 0}}, "arg2" : {"node_type" : "VariableNode", "name" : "pi", "type" : "endogenous", "lag" : 1}}, "arg2" : {"node_type" : "BinaryOpNode", "op" : "*", "arg1" : {"node_type" : "VariableNode", "name" : "sigma", "type" : "parameter", "lag" : 0}, "arg2" : {"node_type" : "BinaryOpNode", "op" : "-", "arg1" : {"node_type" : "VariableNode", "name" : "c", "type" : "modelLocalVariable", "lag" : 0}, "arg2" : {"node_type" : "VariableNode", "name" : "c_LEAD", "type" : "modelLocalVariable", "lag" : 0}}}}}}}}, { "number":2, "line":39, "AST": {"node_type" : "BinaryOpNode", "op" : "=", "arg1" : {"node_type" : "BinaryOpNode", "op" : "*", "arg1" : {"node_type" : "VariableNode", "name" : "Pi", "type" : "modelLocalVariable", "lag" : 0}, "arg2" : {"node_type" : "BinaryOpNode", "op" : "-", "arg1" : {"node_type" : "VariableNode", "name" : "Pi", "type" : "modelLocalVariable", "lag" : 0}, "arg2" : {"node_type" : "NumConstNode", "value" : 1}}}, "arg2" : {"node_type" : "BinaryOpNode", "op" : "+", "arg1" : {"node_type" : "BinaryOpNode", "op" : "*", "arg1" : {"node_type" : "BinaryOpNode", "op" : "/", "arg1" : {"node_type" : "VariableNode", "name" : "theta", "type" : "parameter", "lag" : 0}, "arg2" : {"node_type" : "VariableNode", "name" : "gamma", "type" : "parameter", "lag" : 0}}, "arg2" : {"node_type" : "BinaryOpNode", "op" : "-", "arg1" : {"node_type" : "UnaryOpNode", "op" : "exp", "arg" : {"node_type" : "BinaryOpNode", "op" : "-", "arg1" : {"node_type" : "VariableNode", "name" : "w", "type" : "modelLocalVariable", "lag" : 0}, "arg2" : {"node_type" : "VariableNode", "name" : "z", "type" : "endogenous", "lag" : 0}}}, "arg2" : {"node_type" : "NumConstNode", "value" : 1}}}, "arg2" : {"node_type" : "BinaryOpNode", "op" : "*", "arg1" : {"node_type" : "VariableNode", "name" : "Pi_LEAD", "type" : "modelLocalVariable", "lag" : 0}, "arg2" : {"node_type" : "BinaryOpNode", "op" : "*", "arg1" : {"node_type" : "BinaryOpNode", "op" : "-", "arg1" : {"node_type" : "VariableNode", "name" : "Pi_LEAD", "type" : "modelLocalVariable", "lag" : 0}, "arg2" : {"node_type" : "NumConstNode", "value" : 1}}, "arg2" : {"node_type" : "BinaryOpNode", "op" : "*", "arg1" : {"node_type" : "VariableNode", "name" : "beta", "type" : "parameter", "lag" : 0}, "arg2" : {"node_type" : "UnaryOpNode", "op" : "exp", "arg" : {"node_type" : "BinaryOpNode", "op" : "-", "arg1" : {"node_type" : "BinaryOpNode", "op" : "+", "arg1" : {"node_type" : "VariableNode", "name" : "y", "type" : "endogenous", "lag" : 1}, "arg2" : {"node_type" : "BinaryOpNode", "op" : "+", "arg1" : {"node_type" : "VariableNode", "name" : "d", "type" : "endogenous", "lag" : 1}, "arg2" : {"node_type" : "BinaryOpNode", "op" : "*", "arg1" : {"node_type" : "VariableNode", "name" : "sigma", "type" : "parameter", "lag" : 0}, "arg2" : {"node_type" : "BinaryOpNode", "op" : "-", "arg1" : {"node_type" : "VariableNode", "name" : "c", "type" : "modelLocalVariable", "lag" : 0}, "arg2" : {"node_type" : "VariableNode", "name" : "c_LEAD", "type" : "modelLocalVariable", "lag" : 0}}}}}, "arg2" : {"node_type" : "VariableNode", "name" : "y", "type" : "endogenous", "lag" : 0}}}}}}}}}, { "number":3, "line":40, "AST": {"node_type" : "BinaryOpNode", "op" : "=", "arg1" : {"node_type" : "VariableNode", "name" : "d", "type" : "endogenous", "lag" : 0}, "arg2" : {"node_type" : "BinaryOpNode", "op" : "+", "arg1" : {"node_type" : "BinaryOpNode", "op" : "*", "arg1" : {"node_type" : "VariableNode", "name" : "rhod", "type" : "parameter", "lag" : 0}, "arg2" : {"node_type" : "VariableNode", "name" : "d", "type" : "endogenous", "lag" : -1}}, "arg2" : {"node_type" : "BinaryOpNode", "op" : "*", "arg1" : {"node_type" : "VariableNode", "name" : "sigmad", "type" : "parameter", "lag" : 0}, "arg2" : {"node_type" : "VariableNode", "name" : "epsilond", "type" : "exogenous", "lag" : 0}}}}}, { "number":4, "line":41, "AST": {"node_type" : "BinaryOpNode", "op" : "=", "arg1" : {"node_type" : "VariableNode", "name" : "z", "type" : "endogenous", "lag" : 0}, "arg2" : {"node_type" : "BinaryOpNode", "op" : "+", "arg1" : {"node_type" : "BinaryOpNode", "op" : "*", "arg1" : {"node_type" : "VariableNode", "name" : "rhoz", "type" : "parameter", "lag" : 0}, "arg2" : {"node_type" : "VariableNode", "name" : "z", "type" : "endogenous", "lag" : -1}}, "arg2" : {"node_type" : "BinaryOpNode", "op" : "*", "arg1" : {"node_type" : "VariableNode", "name" : "sigmaz", "type" : "parameter", "lag" : 0}, "arg2" : {"node_type" : "VariableNode", "name" : "epsilonz", "type" : "exogenous", "lag" : 0}}}}}], "variable_mapping":[
], "statements": [{"statementName": "param_init", "name": "beta", "value": "0.997"},
...
```This bug came up in conversation with @MichelJuillard .
For example, this model block:
```
model;
#Pi=exp(pi);
#Pi_LEAD=exp(pi(1));
#Pi_STEADY=exp(pi_STEADY);
#kappa=(gamma/2)*(Pi-1)^2;
#kappa_STEADY=(gamma/2)*(Pi_STEADY-1)^2;
#c=log(1-kappa-eta)+y;
#c_LEAD=log(1-(gamma/2)*(Pi_LEAD-1)^2-eta)+y(1);
#h=y-z;
#w=sigma*c+nu*h-log(1-tauw);
#re=-log(beta)-d(1)+pi_STEADY;
#y_STEADY=(1/(sigma+nu))*(log((1-tauw)*((1-beta)*(Pi_STEADY-1)*Pi_STEADY/theta*gamma+1))-sigma*log(1-kappa_STEADY-eta));
#gdp=log(1-kappa)+y;
#gdp_STEADY=log(1-kappa_STEADY)+y_STEADY;
#dynareOBCMaxArgA1=(0);
#dynareOBCMaxArgB1=(re+phi_pi*(pi-pi_STEADY)+phi_y*(gdp-gdp_STEADY));
#dynareOBCMaxFunc1=max(dynareOBCMaxArgA1,dynareOBCMaxArgB1);
r=(dynareOBCMaxFunc1);
1=beta*exp(d(1)+r-pi(1)+sigma*(c-c_LEAD));
(Pi-1)*Pi=theta/gamma*(exp(w-z)-1)+beta*exp(d(1)+sigma*(c-c_LEAD)+y(1)-y)*(Pi_LEAD-1)*Pi_LEAD;
d=rhod*d(-1)+sigmad*epsilond;
z=rhoz*z(-1)+sigmaz*epsilonz;
end;
```
becomes this in the JSON file (with `json=parse`):
```
...
"model":[
{"lhs": "r", "rhs": "dynareOBCMaxFunc1", "line": 37}
, {"lhs": "1", "rhs": "beta*exp(d(1)+r-pi(1)+sigma*(c-c_LEAD))", "line": 38}
, {"lhs": "Pi*(Pi-1)", "rhs": "theta/gamma*(exp(w-z)-1)+Pi_LEAD*(Pi_LEAD-1)*beta*exp(y(1)+d(1)+sigma*(c-c_LEAD)-y)", "line": 39}
, {"lhs": "d", "rhs": "rhod*d(-1)+sigmad*epsilond", "line": 40}
, {"lhs": "z", "rhs": "rhoz*z(-1)+sigmaz*epsilonz", "line": 41}
]
, "xrefs": {"parameters": [], "endogenous": [], "exogenous": [], "exogenous_deterministic": []}
, "abstract_syntax_tree":[
{ "number":0, "line":37, "AST": {"node_type" : "BinaryOpNode", "op" : "=", "arg1" : {"node_type" : "VariableNode", "name" : "r", "type" : "endogenous", "lag" : 0}, "arg2" : {"node_type" : "VariableNode", "name" : "dynareOBCMaxFunc1", "type" : "modelLocalVariable", "lag" : 0}}}, { "number":1, "line":38, "AST": {"node_type" : "BinaryOpNode", "op" : "=", "arg1" : {"node_type" : "NumConstNode", "value" : 1}, "arg2" : {"node_type" : "BinaryOpNode", "op" : "*", "arg1" : {"node_type" : "VariableNode", "name" : "beta", "type" : "parameter", "lag" : 0}, "arg2" : {"node_type" : "UnaryOpNode", "op" : "exp", "arg" : {"node_type" : "BinaryOpNode", "op" : "+", "arg1" : {"node_type" : "BinaryOpNode", "op" : "-", "arg1" : {"node_type" : "BinaryOpNode", "op" : "+", "arg1" : {"node_type" : "VariableNode", "name" : "d", "type" : "endogenous", "lag" : 1}, "arg2" : {"node_type" : "VariableNode", "name" : "r", "type" : "endogenous", "lag" : 0}}, "arg2" : {"node_type" : "VariableNode", "name" : "pi", "type" : "endogenous", "lag" : 1}}, "arg2" : {"node_type" : "BinaryOpNode", "op" : "*", "arg1" : {"node_type" : "VariableNode", "name" : "sigma", "type" : "parameter", "lag" : 0}, "arg2" : {"node_type" : "BinaryOpNode", "op" : "-", "arg1" : {"node_type" : "VariableNode", "name" : "c", "type" : "modelLocalVariable", "lag" : 0}, "arg2" : {"node_type" : "VariableNode", "name" : "c_LEAD", "type" : "modelLocalVariable", "lag" : 0}}}}}}}}, { "number":2, "line":39, "AST": {"node_type" : "BinaryOpNode", "op" : "=", "arg1" : {"node_type" : "BinaryOpNode", "op" : "*", "arg1" : {"node_type" : "VariableNode", "name" : "Pi", "type" : "modelLocalVariable", "lag" : 0}, "arg2" : {"node_type" : "BinaryOpNode", "op" : "-", "arg1" : {"node_type" : "VariableNode", "name" : "Pi", "type" : "modelLocalVariable", "lag" : 0}, "arg2" : {"node_type" : "NumConstNode", "value" : 1}}}, "arg2" : {"node_type" : "BinaryOpNode", "op" : "+", "arg1" : {"node_type" : "BinaryOpNode", "op" : "*", "arg1" : {"node_type" : "BinaryOpNode", "op" : "/", "arg1" : {"node_type" : "VariableNode", "name" : "theta", "type" : "parameter", "lag" : 0}, "arg2" : {"node_type" : "VariableNode", "name" : "gamma", "type" : "parameter", "lag" : 0}}, "arg2" : {"node_type" : "BinaryOpNode", "op" : "-", "arg1" : {"node_type" : "UnaryOpNode", "op" : "exp", "arg" : {"node_type" : "BinaryOpNode", "op" : "-", "arg1" : {"node_type" : "VariableNode", "name" : "w", "type" : "modelLocalVariable", "lag" : 0}, "arg2" : {"node_type" : "VariableNode", "name" : "z", "type" : "endogenous", "lag" : 0}}}, "arg2" : {"node_type" : "NumConstNode", "value" : 1}}}, "arg2" : {"node_type" : "BinaryOpNode", "op" : "*", "arg1" : {"node_type" : "VariableNode", "name" : "Pi_LEAD", "type" : "modelLocalVariable", "lag" : 0}, "arg2" : {"node_type" : "BinaryOpNode", "op" : "*", "arg1" : {"node_type" : "BinaryOpNode", "op" : "-", "arg1" : {"node_type" : "VariableNode", "name" : "Pi_LEAD", "type" : "modelLocalVariable", "lag" : 0}, "arg2" : {"node_type" : "NumConstNode", "value" : 1}}, "arg2" : {"node_type" : "BinaryOpNode", "op" : "*", "arg1" : {"node_type" : "VariableNode", "name" : "beta", "type" : "parameter", "lag" : 0}, "arg2" : {"node_type" : "UnaryOpNode", "op" : "exp", "arg" : {"node_type" : "BinaryOpNode", "op" : "-", "arg1" : {"node_type" : "BinaryOpNode", "op" : "+", "arg1" : {"node_type" : "VariableNode", "name" : "y", "type" : "endogenous", "lag" : 1}, "arg2" : {"node_type" : "BinaryOpNode", "op" : "+", "arg1" : {"node_type" : "VariableNode", "name" : "d", "type" : "endogenous", "lag" : 1}, "arg2" : {"node_type" : "BinaryOpNode", "op" : "*", "arg1" : {"node_type" : "VariableNode", "name" : "sigma", "type" : "parameter", "lag" : 0}, "arg2" : {"node_type" : "BinaryOpNode", "op" : "-", "arg1" : {"node_type" : "VariableNode", "name" : "c", "type" : "modelLocalVariable", "lag" : 0}, "arg2" : {"node_type" : "VariableNode", "name" : "c_LEAD", "type" : "modelLocalVariable", "lag" : 0}}}}}, "arg2" : {"node_type" : "VariableNode", "name" : "y", "type" : "endogenous", "lag" : 0}}}}}}}}}, { "number":3, "line":40, "AST": {"node_type" : "BinaryOpNode", "op" : "=", "arg1" : {"node_type" : "VariableNode", "name" : "d", "type" : "endogenous", "lag" : 0}, "arg2" : {"node_type" : "BinaryOpNode", "op" : "+", "arg1" : {"node_type" : "BinaryOpNode", "op" : "*", "arg1" : {"node_type" : "VariableNode", "name" : "rhod", "type" : "parameter", "lag" : 0}, "arg2" : {"node_type" : "VariableNode", "name" : "d", "type" : "endogenous", "lag" : -1}}, "arg2" : {"node_type" : "BinaryOpNode", "op" : "*", "arg1" : {"node_type" : "VariableNode", "name" : "sigmad", "type" : "parameter", "lag" : 0}, "arg2" : {"node_type" : "VariableNode", "name" : "epsilond", "type" : "exogenous", "lag" : 0}}}}}, { "number":4, "line":41, "AST": {"node_type" : "BinaryOpNode", "op" : "=", "arg1" : {"node_type" : "VariableNode", "name" : "z", "type" : "endogenous", "lag" : 0}, "arg2" : {"node_type" : "BinaryOpNode", "op" : "+", "arg1" : {"node_type" : "BinaryOpNode", "op" : "*", "arg1" : {"node_type" : "VariableNode", "name" : "rhoz", "type" : "parameter", "lag" : 0}, "arg2" : {"node_type" : "VariableNode", "name" : "z", "type" : "endogenous", "lag" : -1}}, "arg2" : {"node_type" : "BinaryOpNode", "op" : "*", "arg1" : {"node_type" : "VariableNode", "name" : "sigmaz", "type" : "parameter", "lag" : 0}, "arg2" : {"node_type" : "VariableNode", "name" : "epsilonz", "type" : "exogenous", "lag" : 0}}}}}], "variable_mapping":[
], "statements": [{"statementName": "param_init", "name": "beta", "value": "0.997"},
...
```4.7Sébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/1722Provide mapping between model local variable names and indices in the T vector2020-05-12T14:16:43ZTom HoldenProvide mapping between model local variable names and indices in the T vectorPer a request from a DynareOBC user, today I started working on making DynareOBC compatible with Dynare 4.6.
This is proving harder than expected due to the changes to preprocessor output.
Previously, DynareOBC relied on the *_static.m and *_dynamic.m files containing lines giving the value of model local variables (MLVs). This is used in multiple places, e.g. for obtaining the steady state of the augmented model, or for generating code for MLV simulation.
Of course, it is not your duty to support DynareOBC, but having this information in the static and dynamic files was generally useful. For example, in code prepared for the Dynare summer school I used to teach, I used this feature to facilitate writing code for a "perturbation plus" type simulation algorithm (i.e. perturbation used for next period values conditional on today's state and future shock, but given this approximation, the full nonlinear equations + cubature were used to derive today's value).
To make things easy again, it would be sufficient if the generated *_tt.m added comments at the end of each line defining a temporary variable (i.e. T(*)) definition with the name of the MLV to which the given element T(*) corresponds. E.g.:
`#dynareOBCMaxFunc1=max(dynareOBCMaxArgA1,dynareOBCMaxArgB1);`
would become:
`T(14) = max(T(12),T(13)); % dynareOBCMaxFunc1`
Alternatively, the optionally generated JSON could contain this information.
However, I guess that for either of these approaches to be viable as a strategy for DynareOBC to support Dynare 4.6, this would need to be added to Dynare fairly quickly (e.g. for 4.6.2), which may not be viable.
If this is not possible, (and in any case), it would be good to have some documentation of what users can safely assume about the elements of the T vector. A few relevant questions follow:
1. Are all MLVs defined in the model block and used somewhere in the model guaranteed to be in the T vector?
2. If MLV A is defined before MLV B in the model block, then will A definitely be before B in the T vector?
3. Are the MLVs guaranteed to be the first elements of the T vector, or could MLVs and generated temporaries be interspersed?Per a request from a DynareOBC user, today I started working on making DynareOBC compatible with Dynare 4.6.
This is proving harder than expected due to the changes to preprocessor output.
Previously, DynareOBC relied on the *_static.m and *_dynamic.m files containing lines giving the value of model local variables (MLVs). This is used in multiple places, e.g. for obtaining the steady state of the augmented model, or for generating code for MLV simulation.
Of course, it is not your duty to support DynareOBC, but having this information in the static and dynamic files was generally useful. For example, in code prepared for the Dynare summer school I used to teach, I used this feature to facilitate writing code for a "perturbation plus" type simulation algorithm (i.e. perturbation used for next period values conditional on today's state and future shock, but given this approximation, the full nonlinear equations + cubature were used to derive today's value).
To make things easy again, it would be sufficient if the generated *_tt.m added comments at the end of each line defining a temporary variable (i.e. T(*)) definition with the name of the MLV to which the given element T(*) corresponds. E.g.:
`#dynareOBCMaxFunc1=max(dynareOBCMaxArgA1,dynareOBCMaxArgB1);`
would become:
`T(14) = max(T(12),T(13)); % dynareOBCMaxFunc1`
Alternatively, the optionally generated JSON could contain this information.
However, I guess that for either of these approaches to be viable as a strategy for DynareOBC to support Dynare 4.6, this would need to be added to Dynare fairly quickly (e.g. for 4.6.2), which may not be viable.
If this is not possible, (and in any case), it would be good to have some documentation of what users can safely assume about the elements of the T vector. A few relevant questions follow:
1. Are all MLVs defined in the model block and used somewhere in the model guaranteed to be in the T vector?
2. If MLV A is defined before MLV B in the model block, then will A definitely be before B in the T vector?
3. Are the MLVs guaranteed to be the first elements of the T vector, or could MLVs and generated temporaries be interspersed?4.7Sébastien VillemotSébastien Villemothttps://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/1720lmmcp does not work with purely forward or backward models2020-04-11T19:23:48ZJohannes Pfeifer lmmcp does not work with purely forward or backward modelsIn this case, the MCP-tags are ignored due to `perfect_foresight_solver_core` having checks like `if M_.maximum_endo_lead == 0` and immediately calling `sim1_purely_backward` and `sim1_purely_forward`, which do not account for the constraints. A current workaround is using dummy equations.In this case, the MCP-tags are ignored due to `perfect_foresight_solver_core` having checks like `if M_.maximum_endo_lead == 0` and immediately calling `sim1_purely_backward` and `sim1_purely_forward`, which do not account for the constraints. A current workaround is using dummy equations.4.7https://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/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/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/1713Decide minimal MATLAB version requirement for Dynare 4.72020-04-02T16:14:40ZSébastien VillemotDecide minimal MATLAB version requirement for Dynare 4.7We need to decide what will be the minimal version of MATLAB required to run Dynare 4.7.
For Dynare 4.6, our policy has been to support MATLAB versions that are at most 10 years old.
Assuming that Dynare 4.7 is released in 2021, keeping the same policy would imply raising the minimal MATLAB version to R2011a or R2011b (depending on the exact release date).
But we could also decide to change our policy and support less versions. For example, we could go for a 5-years windows, which would imply R2016a or R2016b. Or we could choose something between 5 and 10 years.
Relevant to this discussion is the list of [MATLAB incompatibilities across versions](https://git.dynare.org/Dynare/dynare/-/wikis/MATLAB-Versions). Here are the main benefits that would bring certain requirements:
- *R2013a*: we could get rid of the hack needed to support `intersect(…, 'stable')`
- *R2014a*: we could easily install the minimal required MATLAB version on modern GNU/Linux systems (currently we need a hack to create an artificial `eth0` device with the correct MAC address)
- *R2016a*: we could drop the support for 32-bit versions, which would halve the size of the Windows installer and simplify the build process
- *R2016b*: we could use automatic broadcasting in many places, instead of the obscure `bsxfun` syntaxWe need to decide what will be the minimal version of MATLAB required to run Dynare 4.7.
For Dynare 4.6, our policy has been to support MATLAB versions that are at most 10 years old.
Assuming that Dynare 4.7 is released in 2021, keeping the same policy would imply raising the minimal MATLAB version to R2011a or R2011b (depending on the exact release date).
But we could also decide to change our policy and support less versions. For example, we could go for a 5-years windows, which would imply R2016a or R2016b. Or we could choose something between 5 and 10 years.
Relevant to this discussion is the list of [MATLAB incompatibilities across versions](https://git.dynare.org/Dynare/dynare/-/wikis/MATLAB-Versions). Here are the main benefits that would bring certain requirements:
- *R2013a*: we could get rid of the hack needed to support `intersect(…, 'stable')`
- *R2014a*: we could easily install the minimal required MATLAB version on modern GNU/Linux systems (currently we need a hack to create an artificial `eth0` device with the correct MAC address)
- *R2016a*: we could drop the support for 32-bit versions, which would halve the size of the Windows installer and simplify the build process
- *R2016b*: we could use automatic broadcasting in many places, instead of the obscure `bsxfun` syntax4.7Sébastien VillemotSébastien Villemothttps://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/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/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/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/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/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/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/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.7