dynare issueshttps://git.dynare.org/Dynare/dynare/issues2019-11-29T16:11:56Zhttps://git.dynare.org/Dynare/dynare/issues/1672conditional_forecast should save its output in oo_2019-11-29T16:11:56ZSébastien Villemotconditional_forecast should save its output in oo_Currently, `conditional_forecast` stores its output in a file. This is inconsistent with the rest of Dynare commands, and renders the post-processing of this data less robust, because we have to reload that file from the hard drive (without the guarantee that it comes from the same Dynare session).
The output should be saved in a field of `oo_` (without changing the structure).
`plot_ic_forecast` needs to be adapted. `shock_decomposition` as well, once #1657 is done.
The various fields should also be documented.Currently, `conditional_forecast` stores its output in a file. This is inconsistent with the rest of Dynare commands, and renders the post-processing of this data less robust, because we have to reload that file from the hard drive (without the guarantee that it comes from the same Dynare session).
The output should be saved in a field of `oo_` (without changing the structure).
`plot_ic_forecast` needs to be adapted. `shock_decomposition` as well, once #1657 is done.
The various fields should also be documented.4.6https://git.dynare.org/Dynare/dynare/issues/1669Restore index of functions and commands in the manual2019-12-03T14:45:18ZSébastien VillemotRestore index of functions and commands in the manualIn the texinfo manual, there used to be an index for functions and commands (see https://www.dynare.org/manual/Command-and-Function-Index.html#Command-and-Function-Index).
This has been lost in the conversion to sphinx, and should therefore be restored.
By the way, if this is technically feasible, and index of variables (fields of `M_`, `oo_`, …) would also be useful.In the texinfo manual, there used to be an index for functions and commands (see https://www.dynare.org/manual/Command-and-Function-Index.html#Command-and-Function-Index).
This has been lost in the conversion to sphinx, and should therefore be restored.
By the way, if this is technically feasible, and index of variables (fields of `M_`, `oo_`, …) would also be useful.4.6Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/issues/1668Tighten tolerance for first iteration in solve1()2019-11-27T13:21:54ZMichelJuillardTighten tolerance for first iteration in solve1()Currently solve1() uses the same tolerance level (``tolf``) to decide to start Newton iterations or to terminate them. I suggest the the tolerance above which to start Newton iterations should be tighter.
It is mainly useful for the simulation of purely backward models. When the model is stationary, we expect the trajectory to converge asymptotically towards the steady state. This occurs as long as at least one iteration Newton takes place in each period. If the tolerance criteria is too lax, the simulation remains constant from too early a point.
**I suggest to use the square of ``tolf`` at the start of the computation**
For reference, csolve() always performs one Newton iteration. Matlab's fsolve() and lmmcp use a single tolerance level.Currently solve1() uses the same tolerance level (``tolf``) to decide to start Newton iterations or to terminate them. I suggest the the tolerance above which to start Newton iterations should be tighter.
It is mainly useful for the simulation of purely backward models. When the model is stationary, we expect the trajectory to converge asymptotically towards the steady state. This occurs as long as at least one iteration Newton takes place in each period. If the tolerance criteria is too lax, the simulation remains constant from too early a point.
**I suggest to use the square of ``tolf`` at the start of the computation**
For reference, csolve() always performs one Newton iteration. Matlab's fsolve() and lmmcp use a single tolerance level.https://git.dynare.org/Dynare/dynare/issues/1662Add support for linear models in perfect_foresight_problem MEX2019-11-27T13:11:54ZSébastien VillemotAdd support for linear models in perfect_foresight_problem MEXIn that case, the Jacobian needs not be recomputed for each period.In that case, the Jacobian needs not be recomputed for each period.Sébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/issues/1661`fast` option to dynare does not recompile every time the model changes2019-10-08T07:17:30ZHoutan Bastani`fast` option to dynare does not recompile every time the model changesThe temporary terms of the equations are not printed in the buffer on which the checksum is calculated. Hence, if the model is changed in a term that then becomes a temporary term, the checksum does not change.The temporary terms of the equations are not printed in the buffer on which the checksum is calculated. Hence, if the model is changed in a term that then becomes a temporary term, the checksum does not change.4.6Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/issues/1659Filter out non-positive definite Hessians before Laplace approximation2019-11-21T14:06:17ZJohannes Pfeifer Filter out non-positive definite Hessians before Laplace approximationWe do not check whether the normal approximation underlying the Laplace approximation to the marginal data density makes any sense given the Hessian at hand. That results in wrong output, because the log determinant will be complex and Matlab only prints the real-valued parts.
See https://forum.dynare.org/t/hessian-matrix-at-the-mode-is-not-positive-definite-but-the-marginal-density-is-displayed-anyway/14510/3
Proposed solution: skip the computation of the Hessian is not positive semi-definite and return NaN.We do not check whether the normal approximation underlying the Laplace approximation to the marginal data density makes any sense given the Hessian at hand. That results in wrong output, because the log determinant will be complex and Matlab only prints the real-valued parts.
See https://forum.dynare.org/t/hessian-matrix-at-the-mode-is-not-positive-definite-but-the-marginal-density-is-displayed-anyway/14510/3
Proposed solution: skip the computation of the Hessian is not positive semi-definite and return NaN.4.6Johannes Pfeifer Johannes Pfeifer https://git.dynare.org/Dynare/dynare/issues/1655Move created LaTeX-files to subfolder2019-11-21T14:15:56ZJohannes Pfeifer Move created LaTeX-files to subfolderSee https://git.dynare.org/Dynare/preprocessor/commit/0988a1f755be01b00aab7a458c89d9b63800875d#note_8528See https://git.dynare.org/Dynare/preprocessor/commit/0988a1f755be01b00aab7a458c89d9b63800875d#note_85284.6Johannes Pfeifer Johannes Pfeifer https://git.dynare.org/Dynare/dynare/issues/1654Efficient computation of products of matrix arrays2019-07-03T10:43:38ZWilli Mutschlerwilli@mutschler.euEfficient computation of products of matrix arraysHi,
while extending the identification toolbox I often run into the need to compute a 2d matrix with a 3d array. That is, assume `A is [m x n]`, `B is [n x o x p]` and I need to compute `C(:,:,j)=A*B(:,:,j)`. Currently, I simply run a for loop (as p is dimension of parameters and hence not so large), i.e. the minimal matlab code looks like
```
for j=1:size(B,3)
C(:,:,j) = A*B(:,:,j);
end
```
Is there a more efficient way/trick to do so?Hi,
while extending the identification toolbox I often run into the need to compute a 2d matrix with a 3d array. That is, assume `A is [m x n]`, `B is [n x o x p]` and I need to compute `C(:,:,j)=A*B(:,:,j)`. Currently, I simply run a for loop (as p is dimension of parameters and hence not so large), i.e. the minimal matlab code looks like
```
for j=1:size(B,3)
C(:,:,j) = A*B(:,:,j);
end
```
Is there a more efficient way/trick to do so?https://git.dynare.org/Dynare/dynare/issues/1653kstate2019-07-16T10:27:22ZWilli 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/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/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/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/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@dynare.orgAdd 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 Villemot