dynare issueshttps://git.dynare.org/Dynare/dynare/-/issues2020-05-04T16:22:56Zhttps://git.dynare.org/Dynare/dynare/-/issues/1653kstate2020-05-04T16:22:56ZWilli Mutschlerwilli@mutschler.eukstateHi,
I was wondering if somebody can explain to me the structure of kstate? I am aware that using this is depreciated, as this is a reminiscence of old dynare versions where we did not create auxiliary variables for leads and lags greater than one, but still I find it is used in several functions dealing with e.g. the perturbation solution or identification toolbox.
In any case, I still have problems to get the hang of this. So maybe someone can help me out, given the following simple example:
```
var Y C K A;
varexo eps_A;
parameters alph betta rhoA sigA;
alph = 0.35; betta = 0.99; rhoA = 0.9; sigA = 0.6;
model;
C^(-1)=alph*betta*C(+1)^(-1)*A(+1)*K^(alph-1);
K=A*K(-1)^alph-C;
log(A)=rhoA*log(A(-1))+sigA*eps_A;
Y = A*K(-1)^alph;
end;
```
As I understand, my state variables are K and A, i.e.
- the declaration order is Y C K A
- the DR order is Y K A C
- lead_lag_incidence is equal to
| | Y | C | K | A |
|------|---|---|---|---|
| t-1 | 0 | 0 | 1 | 2 |
| t | 3 | 4 | 5 | 6 |
| t+1 | 0 | 7 | 0 | 8 |
where the number corresponds to the corresponding column number in the dynamic files (i.e. derivative wrt the variable)
Now, the kstate variable is given by:
| | | | |
| ------ | ------ | -----|--|
| 3 | 3 | 4 | 0|
| 4 | 3 | 3 | 0|
| 2 | 2 | 0 | 1|
| 3 | 2 | 0 | 2|
but I do not understand this. As far as I see, there is only one comment in set_state_space.m:
```
% composition of state vector
% col 1: variable; col 2: lead/lag in z(t+1);
% col 3: A cols for t+1 (D); col 4: A cols for t (E)
```
but what is the meaning of z(t+1), A, D and E or to which state space representation do these correspond to?
Thanks!Hi,
I was wondering if somebody can explain to me the structure of kstate? I am aware that using this is depreciated, as this is a reminiscence of old dynare versions where we did not create auxiliary variables for leads and lags greater than one, but still I find it is used in several functions dealing with e.g. the perturbation solution or identification toolbox.
In any case, I still have problems to get the hang of this. So maybe someone can help me out, given the following simple example:
```
var Y C K A;
varexo eps_A;
parameters alph betta rhoA sigA;
alph = 0.35; betta = 0.99; rhoA = 0.9; sigA = 0.6;
model;
C^(-1)=alph*betta*C(+1)^(-1)*A(+1)*K^(alph-1);
K=A*K(-1)^alph-C;
log(A)=rhoA*log(A(-1))+sigA*eps_A;
Y = A*K(-1)^alph;
end;
```
As I understand, my state variables are K and A, i.e.
- the declaration order is Y C K A
- the DR order is Y K A C
- lead_lag_incidence is equal to
| | Y | C | K | A |
|------|---|---|---|---|
| t-1 | 0 | 0 | 1 | 2 |
| t | 3 | 4 | 5 | 6 |
| t+1 | 0 | 7 | 0 | 8 |
where the number corresponds to the corresponding column number in the dynamic files (i.e. derivative wrt the variable)
Now, the kstate variable is given by:
| | | | |
| ------ | ------ | -----|--|
| 3 | 3 | 4 | 0|
| 4 | 3 | 3 | 0|
| 2 | 2 | 0 | 1|
| 3 | 2 | 0 | 2|
but I do not understand this. As far as I see, there is only one comment in set_state_space.m:
```
% composition of state vector
% col 1: variable; col 2: lead/lag in z(t+1);
% col 3: A cols for t+1 (D); col 4: A cols for t (E)
```
but what is the meaning of z(t+1), A, D and E or to which state space representation do these correspond to?
Thanks!https://git.dynare.org/Dynare/dynare/-/issues/1652Crash in bytecode2019-12-03T14:45:18ZSébastien VillemotCrash in bytecodeI attach an example ([surprise_solution.zip](/uploads/17158ceefc6fbf59f6810d17cbcdc084/surprise_solution.zip)) that crashes bytecode (just by running `surprise_solution_2019_05_20.mod`).
The problem can be reproduced both with unstable and 4.5.
*Note:* comes from https://forum.dynare.org/t/matlab-shutdown-deterministic-solution-stack-solve-algo-1/13882I attach an example ([surprise_solution.zip](/uploads/17158ceefc6fbf59f6810d17cbcdc084/surprise_solution.zip)) that crashes bytecode (just by running `surprise_solution_2019_05_20.mod`).
The problem can be reproduced both with unstable and 4.5.
*Note:* comes from https://forum.dynare.org/t/matlab-shutdown-deterministic-solution-stack-solve-algo-1/138824.6Sébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/1651dynare_sensitivity without exogenous variables2019-09-10T09:27:19Zrobvanharreveltdynare_sensitivity without exogenous variablesWhen `dynare_sensitivity` is used for a model without exogenous variables, the following error occurs:
```
Reference to non-existent field 'ghu'.
Error in kalman_transition_matrix (line 42)
B = dr.ghu(iv,:);
```
See the attached file [test1.mod](/uploads/2c7fa958781bb4ea203ecb1d484c9c8d/test1.mod). An easy workaround is to create a dummy exogenous variable (see attached file [test2.mod](/uploads/31ea2681c8f6b2701ed9da63e39c8968/test2.mod)), but it would help if the error message explains that the code does not work for models without exogenous variables.
This issue is similar to issue https://git.dynare.org/Dynare/dynare/issues/1633.When `dynare_sensitivity` is used for a model without exogenous variables, the following error occurs:
```
Reference to non-existent field 'ghu'.
Error in kalman_transition_matrix (line 42)
B = dr.ghu(iv,:);
```
See the attached file [test1.mod](/uploads/2c7fa958781bb4ea203ecb1d484c9c8d/test1.mod). An easy workaround is to create a dummy exogenous variable (see attached file [test2.mod](/uploads/31ea2681c8f6b2701ed9da63e39c8968/test2.mod)), but it would help if the error message explains that the code does not work for models without exogenous variables.
This issue is similar to issue https://git.dynare.org/Dynare/dynare/issues/1633.4.6Marco RattoMarco Rattohttps://git.dynare.org/Dynare/dynare/-/issues/1650allow to associate initial conditions to shocks in shocks grouping for shock ...2020-01-21T17:39:56ZMarco Rattoallow to associate initial conditions to shocks in shocks grouping for shock decomposition plotsIt would be useful to have an interface for a command like `init2shocks`, which accepts couples of names. first an endo name, second a shock name
```
init2shocks;
endoname1 exoname1;
endoname2 exoname1;
endoname3 exoname2;
...
;
```
there can be multiple endo names for one exo, but NOT viceversa.
The preprocessor should translate this into a cell matrix as follows:
```
M_.init2shocks = {
'endoname1','exoname1';
'endoname2','exoname1';
'endoname3','exoname2';
};
```
default will be: `M_.init2shocks = {};`
Then we need a new option `init2shocks` for `plot_shock_decomposition(init2shocks)`. If it is called, the preprocessor will trigger
```
options_.plot_shock_decomp.init2shocks = M_.init2shocks;
```
otherwise it should be empty (by default).
```
options_.plot_shock_decomp.init2shocks =[];
```
with this definitions, plot_shock_decompo will attribute the initial condition effect of endo variables to the shock/shock group.It would be useful to have an interface for a command like `init2shocks`, which accepts couples of names. first an endo name, second a shock name
```
init2shocks;
endoname1 exoname1;
endoname2 exoname1;
endoname3 exoname2;
...
;
```
there can be multiple endo names for one exo, but NOT viceversa.
The preprocessor should translate this into a cell matrix as follows:
```
M_.init2shocks = {
'endoname1','exoname1';
'endoname2','exoname1';
'endoname3','exoname2';
};
```
default will be: `M_.init2shocks = {};`
Then we need a new option `init2shocks` for `plot_shock_decomposition(init2shocks)`. If it is called, the preprocessor will trigger
```
options_.plot_shock_decomp.init2shocks = M_.init2shocks;
```
otherwise it should be empty (by default).
```
options_.plot_shock_decomp.init2shocks =[];
```
with this definitions, plot_shock_decompo will attribute the initial condition effect of endo variables to the shock/shock group.4.6Sébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/1649new plot_shock_decomposition options2019-12-06T15:30:45ZMarco Rattonew plot_shock_decomposition optionsIt would be useful to allow the preprocessor to take the following new options, both for `plot_shock_decomposition` and `initial_condition_decomposition`:
* `diff`: plots the first difference of the requested variable
* `flip`: flip the requested variables with sign change (e.g. useful to flip the concept of an exchange rate or trade balance or deficit/surplus variable without having to define it in model definition)
I have already provisions ready to push.It would be useful to allow the preprocessor to take the following new options, both for `plot_shock_decomposition` and `initial_condition_decomposition`:
* `diff`: plots the first difference of the requested variable
* `flip`: flip the requested variables with sign change (e.g. useful to flip the concept of an exchange rate or trade balance or deficit/surplus variable without having to define it in model definition)
I have already provisions ready to push.4.6Marco RattoMarco Rattohttps://git.dynare.org/Dynare/dynare/-/issues/1648Store info on deflator growth factor in M_ for each endo variables2019-12-13T17:29:34ZMarco RattoStore info on deflator growth factor in M_ for each endo variablesAssume we define a model with trend variables:
```
trend_var(growth_factor = exp(GYTREND0)) YTREND0;
trend_var(growth_factor = exp(GP0)) PY0;
// real variable
var (deflator=YTREND0) Y;
// price index
var (deflator=PY0) PY;
// nominal variable
var (deflator=YTREND0*PY0) YN;
```
It would be extremely useful if we had trace in `M_` of the preprocessed trends, e.g. similarly to name/long_name, there could be a cell list M_.endo_growth_factor, which would contain for the above example:
```
M_.endo_growth_factor(1) = {'exp(GYTREND0)'};
M_.endo_growth_factor(2) = {'exp(GP0)'}
M_.endo_growth_factor(3) = {'exp(GYTREND0)*exp(GP0)'};
```
for variables not trending it would be:
```
M_.endo_growth_factor(4) = {'1'};
```Assume we define a model with trend variables:
```
trend_var(growth_factor = exp(GYTREND0)) YTREND0;
trend_var(growth_factor = exp(GP0)) PY0;
// real variable
var (deflator=YTREND0) Y;
// price index
var (deflator=PY0) PY;
// nominal variable
var (deflator=YTREND0*PY0) YN;
```
It would be extremely useful if we had trace in `M_` of the preprocessed trends, e.g. similarly to name/long_name, there could be a cell list M_.endo_growth_factor, which would contain for the above example:
```
M_.endo_growth_factor(1) = {'exp(GYTREND0)'};
M_.endo_growth_factor(2) = {'exp(GP0)'}
M_.endo_growth_factor(3) = {'exp(GYTREND0)*exp(GP0)'};
```
for variables not trending it would be:
```
M_.endo_growth_factor(4) = {'1'};
```4.6https://git.dynare.org/Dynare/dynare/-/issues/1647Add silent mode to perfect foresight simulations2019-09-12T12:50:55ZJohannes Pfeifer Add silent mode to perfect foresight simulationsSee https://forum.dynare.org/t/supressing-output-in-steady-and-simul-commands/13916See https://forum.dynare.org/t/supressing-output-in-steady-and-simul-commands/139164.6Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/-/issues/1646Save var_list_ used in stoch_simul to oo_2019-09-12T13:07:50ZJohannes Pfeifer Save var_list_ used in stoch_simul to oo_If variables are selected after `stoch_simul`, fields like `oo_.var` will be matrices of the dimension of `var_list_`. But the info on `var_list_` is not stored. So if one loads results from a `_results.mat`-file, there is no way to recover to which variables the entries in `oo_.var` belong.
The question is how to store this info as one can have several different `stoch_simul`-commands in a mod-file.If variables are selected after `stoch_simul`, fields like `oo_.var` will be matrices of the dimension of `var_list_`. But the info on `var_list_` is not stored. So if one loads results from a `_results.mat`-file, there is no way to recover to which variables the entries in `oo_.var` belong.
The question is how to store this info as one can have several different `stoch_simul`-commands in a mod-file.4.6Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/-/issues/1645Provide an example for ramsey_policy and osr2020-01-10T17:30:50ZSébastien VillemotProvide an example for ramsey_policy and osrTo be distributed on the website and in the `examples` subdir.
Suggested by Aurélien Poissonnier.To be distributed on the website and in the `examples` subdir.
Suggested by Aurélien Poissonnier.4.6Johannes Pfeifer Johannes Pfeifer https://git.dynare.org/Dynare/dynare/-/issues/1644How to include m2html when compiling the MEX for MATLAB2019-05-22T15:36:00ZWilli Mutschlerwilli@mutschler.euHow to include m2html when compiling the MEX for MATLABHi, just a minor (and not really important) question, but still for completeness.
Whenever I compile the preprocessor I always get
`M2HTML documentation: no` .
I did download m2html from https://www.artefact.tk/software/matlab/m2html/, unzipped it and added the path to matlab. I am on Ubuntu. Am I doing anything wrong?Hi, just a minor (and not really important) question, but still for completeness.
Whenever I compile the preprocessor I always get
`M2HTML documentation: no` .
I did download m2html from https://www.artefact.tk/software/matlab/m2html/, unzipped it and added the path to matlab. I am on Ubuntu. Am I doing anything wrong?Sébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/1643Implement pruning at order>32021-01-21T16:23:44ZJohannes Pfeifer Implement pruning at order>3The algorithm should follow Andreasen et al. (2018) as already implemented in `simult_.m` for orders 2 and 3. Should be done in the C++ routines of `dynare_simul_` as discussed in https://git.dynare.org/Dynare/dynare/commit/1e92e308b9d0301108d18d7256f47655097f20cb#note_8364The algorithm should follow Andreasen et al. (2018) as already implemented in `simult_.m` for orders 2 and 3. Should be done in the C++ routines of `dynare_simul_` as discussed in https://git.dynare.org/Dynare/dynare/commit/1e92e308b9d0301108d18d7256f47655097f20cb#note_83644.8Normann RionNormann Rionhttps://git.dynare.org/Dynare/dynare/-/issues/1642Bug in analytical computations of second-order params derivs (d2A and d2Om)2019-03-27T11:52:59ZWilli Mutschlerwilli@mutschler.euBug in analytical computations of second-order params derivs (d2A and d2Om)The function `get_first_order_solution_params_deriv.m` (previously `getH.m`) does not compute the second-order derivatives `d2A` and `d2Om` correctly when using analytical derivatives (kronflag=0|1). If we use numerical derivatives (kronflag=-1|-2) the computations are correct.
To replicate the bug, I looked at the Brock and Mirman model (i.e. RBC model with log utility and full depreciation), where we know analytically the policy functions, i.e. also the Kalman transition matrices of a first-order approximation (A, B and Om) analytically. Hence, using symbolic computations it is possible to compute the true `d2A` and `d2Om` and compare the values to dynare.
Here is a mod file to replicate the bug:
[BrockMirmanBug.mod](/uploads/006601083ca694efc36c5b9b396c3aa9/BrockMirmanBug.mod)
and the corresponding matlab file that computes the true objects of the Brock Mirman Model analytically using Matlab's symbolic toolbox:
[BrockMirmanTruePolicyAndDerivatives.m](/uploads/f1cf3e22d26d7e904b6e49764520ee5e/BrockMirmanTruePolicyAndDerivatives.m)
@rattoma is already aware of this bug.The function `get_first_order_solution_params_deriv.m` (previously `getH.m`) does not compute the second-order derivatives `d2A` and `d2Om` correctly when using analytical derivatives (kronflag=0|1). If we use numerical derivatives (kronflag=-1|-2) the computations are correct.
To replicate the bug, I looked at the Brock and Mirman model (i.e. RBC model with log utility and full depreciation), where we know analytically the policy functions, i.e. also the Kalman transition matrices of a first-order approximation (A, B and Om) analytically. Hence, using symbolic computations it is possible to compute the true `d2A` and `d2Om` and compare the values to dynare.
Here is a mod file to replicate the bug:
[BrockMirmanBug.mod](/uploads/006601083ca694efc36c5b9b396c3aa9/BrockMirmanBug.mod)
and the corresponding matlab file that computes the true objects of the Brock Mirman Model analytically using Matlab's symbolic toolbox:
[BrockMirmanTruePolicyAndDerivatives.m](/uploads/f1cf3e22d26d7e904b6e49764520ee5e/BrockMirmanTruePolicyAndDerivatives.m)
@rattoma is already aware of this bug.Marco RattoMarco Rattohttps://git.dynare.org/Dynare/dynare/-/issues/1641Fix dyn_first_order_solver for models without lagged variables2019-03-08T16:51:44ZJohannes Pfeifer Fix dyn_first_order_solver for models without lagged variablesThe model
```
// Declare variables
var y r k b tax agov wage gama s cf cs;
// Declare parameter values
parameters cbeta cdelta cphi ctheta cn ca cd cb ct da ft;
cbeta=0.98;
cdelta=5;
cphi=0.2058;
cn=1;
ctheta=0.2;
ca=0.3;
cd=0.97;
cb=0.09;
ct=0.05;
ft=0.1;
da=2;
// predetermined_variables k;
model;
y= da*k^ctheta;
r= da*ctheta*k^(ctheta-1);
wage= da*(1-ctheta)*k^ctheta;
gama(+1)=cn*(cd+cphi*agov^ca)*k(+1)^ctheta/k^ctheta;
tax=ct*wage+ft*r*(b+k);
b(+1)*cn*(cd+cphi*agov^ca)=agov+r*b-tax;
s=wage*(1-ct)*cbeta^cdelta*(r*(1-ft))^(cdelta-1)/(1+cbeta^cdelta*(r*(1-ft))^(cdelta-1));
k(+1)+b(+1)=s/(cn*(cd+cphi*agov^ca));
b=cb*y;
cf=wage*(1-ct)/(1+cbeta^(-cdelta)*(r*(1-ft))^(1-cdelta));
cs=wage*(1-ct)*(cbeta*r*(1-ft))^(1-cdelta)/(1+cbeta^(0-cdelta)*(r*(1-ft))^(1-cdelta));
end;
initval;
k =0.1;
y = da*k^ctheta;
r= da*ctheta*k^(ctheta-1);
wage= da*(1-ctheta)*k^ctheta;
b =cb*y;
tax =ct*wage;
agov =0.1;
s=(wage-tax)*cbeta^cdelta*r^(cdelta-1)/(1+cbeta^cdelta*r^(cdelta-1));
end;
steady;
// check;
stoch_simul(order=1);
```
crashes `dyn_first_order_solver` due to non-conformable matrix dimensions in ` E(row_indx_de_1,index_e1) = -aa(row_indx,index_e);`
Setting the predetermined variables correctly solves the issue.The model
```
// Declare variables
var y r k b tax agov wage gama s cf cs;
// Declare parameter values
parameters cbeta cdelta cphi ctheta cn ca cd cb ct da ft;
cbeta=0.98;
cdelta=5;
cphi=0.2058;
cn=1;
ctheta=0.2;
ca=0.3;
cd=0.97;
cb=0.09;
ct=0.05;
ft=0.1;
da=2;
// predetermined_variables k;
model;
y= da*k^ctheta;
r= da*ctheta*k^(ctheta-1);
wage= da*(1-ctheta)*k^ctheta;
gama(+1)=cn*(cd+cphi*agov^ca)*k(+1)^ctheta/k^ctheta;
tax=ct*wage+ft*r*(b+k);
b(+1)*cn*(cd+cphi*agov^ca)=agov+r*b-tax;
s=wage*(1-ct)*cbeta^cdelta*(r*(1-ft))^(cdelta-1)/(1+cbeta^cdelta*(r*(1-ft))^(cdelta-1));
k(+1)+b(+1)=s/(cn*(cd+cphi*agov^ca));
b=cb*y;
cf=wage*(1-ct)/(1+cbeta^(-cdelta)*(r*(1-ft))^(1-cdelta));
cs=wage*(1-ct)*(cbeta*r*(1-ft))^(1-cdelta)/(1+cbeta^(0-cdelta)*(r*(1-ft))^(1-cdelta));
end;
initval;
k =0.1;
y = da*k^ctheta;
r= da*ctheta*k^(ctheta-1);
wage= da*(1-ctheta)*k^ctheta;
b =cb*y;
tax =ct*wage;
agov =0.1;
s=(wage-tax)*cbeta^cdelta*r^(cdelta-1)/(1+cbeta^cdelta*r^(cdelta-1));
end;
steady;
// check;
stoch_simul(order=1);
```
crashes `dyn_first_order_solver` due to non-conformable matrix dimensions in ` E(row_indx_de_1,index_e1) = -aa(row_indx,index_e);`
Setting the predetermined variables correctly solves the issue.4.6https://git.dynare.org/Dynare/dynare/-/issues/1640Build issues under Arch Linux (Dynare 4.5.7, Octave 5.1.0)2019-03-07T15:27:58ZAngelo SaltonBuild issues under Arch Linux (Dynare 4.5.7, Octave 5.1.0)Hello,
I'm forwarding an issue found by a fellow Arch user on [AUR](https://aur.archlinux.org/packages/dynare/):
> To run smoothly under Octave 5.1.0 I had to symlink the libs from the Octave folder:
>
> ```
> ln -s /usr/lib/octave/5.1.0/liboctave.so /usr/lib/liboctave.so
> ln -s /usr/lib/octave/5.1.0/liboctinterp.so /usr/lib/liboctinterp.so
> ln -s /usr/lib/octave/5.1.0/liboctinterp.so /usr/lib/liboctinterp.so.6
> ```
>
> Just setting the LDFLAGS during the build won't do the trick.Hello,
I'm forwarding an issue found by a fellow Arch user on [AUR](https://aur.archlinux.org/packages/dynare/):
> To run smoothly under Octave 5.1.0 I had to symlink the libs from the Octave folder:
>
> ```
> ln -s /usr/lib/octave/5.1.0/liboctave.so /usr/lib/liboctave.so
> ln -s /usr/lib/octave/5.1.0/liboctinterp.so /usr/lib/liboctinterp.so
> ln -s /usr/lib/octave/5.1.0/liboctinterp.so /usr/lib/liboctinterp.so.6
> ```
>
> Just setting the LDFLAGS during the build won't do the trick.Sébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/1639Add the possibility to use Matlab's namespace in model block2019-11-27T13:11:53ZStéphane Adjemianstepan@adjemian.euAdd the possibility to use Matlab's namespace in model block... or in `steady_state_model` block, where it should be possible to write something like:
```
z = example.z_steadystate();
```
provided that the file `+example/z_steadystate` exists.... or in `steady_state_model` block, where it should be possible to write something like:
```
z = example.z_steadystate();
```
provided that the file `+example/z_steadystate` exists.4.6Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/-/issues/1638Octave: persistent variables do not get set in prior_draw2019-03-18T14:23:00ZWilli Mutschlerwilli@mutschler.euOctave: persistent variables do not get set in prior_drawI noticed that running `tests/identification/as2007/as2007.mod` of the master branch with Octave (ver. 4.4.1) does not work with the following error:
```
Monte Carlo Testing
error: 'a' undefined near line 40 column 19
error: called from
gamrnd at line 40 column 7
gamrnd at line 122 column 27
prior_draw at line 128 column 24
dynare_identification at line 529 column 20
driver at line 247 column 1
dynare at line 288 column 1
stopped in /home/wmutschl/dynare/wip/matlab/missing/stats/gamrnd.m at line 40
40: b = ones(size(a));
```
I think the reason is that in `dynare_identification` in line 155/157 `prior_draw(bayestopt_, options_.prior_trunc, false)` is called once to initialize the following persistent variables in `prior_draw`:
```
persistent p6 p7 p3 p4 lb ub
persistent uniform_index gaussian_index gamma_index beta_index inverse_gamma_1_index inverse_gamma_2_index weibull_index
persistent uniform_draws gaussian_draws gamma_draws beta_draws inverse_gamma_1_draws inverse_gamma_2_draws weibull_draws
```
Once we have that, `prior_draw()` generates a new draw. At least this is the ways it works in Matlab and the test file runs through.
However, in Octave the persistent variables do not get set for some reason, and hence `gamrnd` is called with undefined inputs, as far as I can see.I noticed that running `tests/identification/as2007/as2007.mod` of the master branch with Octave (ver. 4.4.1) does not work with the following error:
```
Monte Carlo Testing
error: 'a' undefined near line 40 column 19
error: called from
gamrnd at line 40 column 7
gamrnd at line 122 column 27
prior_draw at line 128 column 24
dynare_identification at line 529 column 20
driver at line 247 column 1
dynare at line 288 column 1
stopped in /home/wmutschl/dynare/wip/matlab/missing/stats/gamrnd.m at line 40
40: b = ones(size(a));
```
I think the reason is that in `dynare_identification` in line 155/157 `prior_draw(bayestopt_, options_.prior_trunc, false)` is called once to initialize the following persistent variables in `prior_draw`:
```
persistent p6 p7 p3 p4 lb ub
persistent uniform_index gaussian_index gamma_index beta_index inverse_gamma_1_index inverse_gamma_2_index weibull_index
persistent uniform_draws gaussian_draws gamma_draws beta_draws inverse_gamma_1_draws inverse_gamma_2_draws weibull_draws
```
Once we have that, `prior_draw()` generates a new draw. At least this is the ways it works in Matlab and the test file runs through.
However, in Octave the persistent variables do not get set for some reason, and hence `gamrnd` is called with undefined inputs, as far as I can see.Sébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/1637Investigate parsing of attached mod-file2019-02-05T17:03:42ZJohannes Pfeifer Investigate parsing of attached mod-fileThe file [Q4_disc.mod](/uploads/a84d498060bfb51694ce8e527f06a8de/Q4_disc.mod) seems to not be correctly parsed. The parameter `lambda` is defined, but is not set by the preprocessor.The file [Q4_disc.mod](/uploads/a84d498060bfb51694ce8e527f06a8de/Q4_disc.mod) seems to not be correctly parsed. The parameter `lambda` is defined, but is not set by the preprocessor.Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/-/issues/1636Fix infinite loop in mr_hessian2019-02-05T17:03:42ZJohannes Pfeifer Fix infinite loop in mr_hessian@rattoma `mr_hessian` contains the loop
```
while (fx-f0)==0
hess_info.h1(i)= hess_info.h1(i)*2;
xh1(i)=x(i)+hess_info.h1(i);
[fx,exit_flag,ffx]=penalty_objective_function(xh1,func,penalty,varargin{:});
ic=1;
end
```
That loop does not have a proper termination criterion. I have a mod-file where `hess_info.h1(i)` becomes 0 so that it is always true that `fx=f0`. So either we condition on `ic` also being smaller than a particlar number, or we need to check that `hess_info.h1(i)*2` is not 0.@rattoma `mr_hessian` contains the loop
```
while (fx-f0)==0
hess_info.h1(i)= hess_info.h1(i)*2;
xh1(i)=x(i)+hess_info.h1(i);
[fx,exit_flag,ffx]=penalty_objective_function(xh1,func,penalty,varargin{:});
ic=1;
end
```
That loop does not have a proper termination criterion. I have a mod-file where `hess_info.h1(i)` becomes 0 so that it is always true that `fx=f0`. So either we condition on `ic` also being smaller than a particlar number, or we need to check that `hess_info.h1(i)*2` is not 0.4.6Marco RattoMarco Rattohttps://git.dynare.org/Dynare/dynare/-/issues/1635Bug in shock_decomposition2019-01-22T18:42:02Zjbejarro78Bug in shock_decompositionAfter running an estimation and the shock_decomposition command, I realize that shock_decomposition of an observed variable x is not consistent with the shock_decomposition computed by DYNARE. The problem is that DYNARE generates some Auxiliary ENDO and LAG variables that change variables order for the shock_decomposition and therefore shock_decomposition is not conssitent with that observed variable. Could you fix that? or could I avoide that DYNARE does not generates those auxiliary variables.After running an estimation and the shock_decomposition command, I realize that shock_decomposition of an observed variable x is not consistent with the shock_decomposition computed by DYNARE. The problem is that DYNARE generates some Auxiliary ENDO and LAG variables that change variables order for the shock_decomposition and therefore shock_decomposition is not conssitent with that observed variable. Could you fix that? or could I avoide that DYNARE does not generates those auxiliary variables.https://git.dynare.org/Dynare/dynare/-/issues/1634Bug in positive/negative IRFs in Dynare++2019-02-05T20:00:07ZJohannes Pfeifer Bug in positive/negative IRFs in Dynare++See
https://forum.dynare.org/t/asymmetric-irfs-at-first-order-in-dynare/12246/4
The issue seems to have not yet been solved.See
https://forum.dynare.org/t/asymmetric-irfs-at-first-order-in-dynare/12246/4
The issue seems to have not yet been solved.4.6Sébastien VillemotSébastien Villemot