dynare issueshttps://git.dynare.org/Dynare/dynare/-/issues2020-03-12T17:12:34Zhttps://git.dynare.org/Dynare/dynare/-/issues/2Be more flexible about variable declarations2020-03-12T17:12:34ZSébastien VillemotBe more flexible about variable declarationsRequest by Pascal Jacquinot, in order to facilitate model development.
If I understand correctly, he would like that Dynare simply ignores endogenous/exogenous variables that are never used in the model (instead of complaining about number of variables ≠ number of equations)
Request by Pascal Jacquinot, in order to facilitate model development.
If I understand correctly, he would like that Dynare simply ignores endogenous/exogenous variables that are never used in the model (instead of complaining about number of variables ≠ number of equations)
4.5Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/-/issues/419Expand model_diagnostics to test whether the model is truly linear2019-06-19T15:38:18ZJohannes Pfeifer Expand model_diagnostics to test whether the model is truly linearOften users specify model(linear), but don't enter all FOCs correctly. Testing in model_diagnostics whether all equations are linear and displaying the wrong equations would provide a valuable diagnostic tool. Alternatively, the preprocessor could check whether the Hessian g2 is a zero matrix if the linear option is specified.
Often users specify model(linear), but don't enter all FOCs correctly. Testing in model_diagnostics whether all equations are linear and displaying the wrong equations would provide a valuable diagnostic tool. Alternatively, the preprocessor could check whether the Hessian g2 is a zero matrix if the linear option is specified.
4.5Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/-/issues/420Perfect foresight simulator with bytecode/block option is brocken if dynare i...2019-06-19T15:38:18ZStéphane Adjemianstepan@adjemian.euPerfect foresight simulator with bytecode/block option is brocken if dynare is compiled with --enable-openmp flag4.5https://git.dynare.org/Dynare/dynare/-/issues/430Deal with treatment of presample2019-06-19T15:38:18ZJohannes Pfeifer Deal with treatment of presample#429 introduces an error messsage for non-linear estimation with a `presample` being specified. This incorrectly used the first `presample` observations to compute the likelihood despite the manual saying that they are skipped. In the long-run, we might either want to actually use the presample to initialize the state matrix (e.g. as an option for initialization similar to using the ergodic state variance matrix of the linear model) or just skip the first `presample` periods by only using the observations `presample+1:end`
Another place where presample shows up is `bvar_toolbox.m`. Here we should clarify the distinction to the training sample in `options_.bvar_prior_train`
#429 introduces an error messsage for non-linear estimation with a `presample` being specified. This incorrectly used the first `presample` observations to compute the likelihood despite the manual saying that they are skipped. In the long-run, we might either want to actually use the presample to initialize the state matrix (e.g. as an option for initialization similar to using the ergodic state variance matrix of the linear model) or just skip the first `presample` periods by only using the observations `presample+1:end`
Another place where presample shows up is `bvar_toolbox.m`. Here we should clarify the distinction to the training sample in `options_.bvar_prior_train`
4.5https://git.dynare.org/Dynare/dynare/-/issues/435Potentially automatically detect non-stationary model and change QZ criterium2019-06-19T15:38:18ZJohannes Pfeifer Potentially automatically detect non-stationary model and change QZ criteriumWhile the manual states that `kalman_algo` automatically uses the correct filter for stationary and nonstationary models, this case never seems to happen. If the user does not specify that the model is non-stationary, initial_estimation_checks will throw out an error, because the QZ criterium is too high for the BK conditions to be satisfied. It might be a good idea to check in `initial_estimation_checks` for the presence of a unit root, throw out a warning, and set the `qz_criterium` to 0.999999 if a unit root is detected.
While the manual states that `kalman_algo` automatically uses the correct filter for stationary and nonstationary models, this case never seems to happen. If the user does not specify that the model is non-stationary, initial_estimation_checks will throw out an error, because the QZ criterium is too high for the BK conditions to be satisfied. It might be a good idea to check in `initial_estimation_checks` for the presence of a unit root, throw out a warning, and set the `qz_criterium` to 0.999999 if a unit root is detected.
4.5https://git.dynare.org/Dynare/dynare/-/issues/438investigate problem deleting files with ms-sbvar on windows 72019-06-19T15:38:18ZHoutan Bastaniinvestigate problem deleting files with ms-sbvar on windows 7This is about the problem we discussed with ms_estimation under Windows 7, Matlab 7.8.0 (R2009a). In a nutshell, if msvar is run more than once in a single Matlab session, the init files created on the first run cannot subsequently be deleted. This is a problem as when the init files are not deleted, changes to the model made in the mod file are not reflected in the dynare run. Matlab does not believe that it has any files open – type fopen(‘all’) to check – but windows thinks that Matlab does in fact have these files open. A guess is that the C code may not have fflush()ed the write buffer to the files before closing.
Thanks for your help.
- Roland
To replicate the problem:
· Starting from a clean directory with only RM_test.mod and data_SwitchingFed11_demeaned.dat, run dynare. Should be successful.
· Run dynare a second time. The log file output I get is pasted below. Windows cannot delete “init_RM_test.dat” and other files because they are said to be in use by Matlab.
(email 28 June 2013 12:00:08 PM GMT+02:00)
This is about the problem we discussed with ms_estimation under Windows 7, Matlab 7.8.0 (R2009a). In a nutshell, if msvar is run more than once in a single Matlab session, the init files created on the first run cannot subsequently be deleted. This is a problem as when the init files are not deleted, changes to the model made in the mod file are not reflected in the dynare run. Matlab does not believe that it has any files open – type fopen(‘all’) to check – but windows thinks that Matlab does in fact have these files open. A guess is that the C code may not have fflush()ed the write buffer to the files before closing.
Thanks for your help.
- Roland
To replicate the problem:
· Starting from a clean directory with only RM_test.mod and data_SwitchingFed11_demeaned.dat, run dynare. Should be successful.
· Run dynare a second time. The log file output I get is pasted below. Windows cannot delete “init_RM_test.dat” and other files because they are said to be in use by Matlab.
(email 28 June 2013 12:00:08 PM GMT+02:00)
4.5Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/-/issues/477use of tags in write_latex_dynamic_model2019-06-19T15:38:16ZMarco Rattouse of tags in write_latex_dynamic_modelwould it be possible to add tag info in the write_latex_dynamic_model, e.g. by inserting a simple text line with tags info before each equation?
would it be possible to add tag info in the write_latex_dynamic_model, e.g. by inserting a simple text line with tags info before each equation?
4.5Houtan BastaniHoutan Bastanihttps://git.dynare.org/Dynare/dynare/-/issues/503Check use and precedence of jscale and document it.2019-06-19T15:38:16ZJohannes Pfeifer Check use and precedence of jscale and document it.The use of `bayestopt_.mh_jscale` and `bayestopt_.jscale` as well as `options_.mh_jscale` is confusing an potentially buggy (see also http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=5072). In `dynare_estimation_1` we use
```
mh_scale_fname = [M_.fname '_optimal_mh_scale_parameter.mat'];
if exist(mh_scale_fname)
if options_.mode_compute == 0
tmp = load(mh_scale_fname,'Scale');
bayestopt_.mh_jscale = tmp.Scale;
clear tmp;
else
% remove the file if mode_compute ~= 0
delete('mh_scale_fname')
end
end
```
to read out the `mh_jscale` from a previous run of `mode_compute=6`. But this is after `dynare_estimation_init` where the `mh_jscale` seems to be translated into the `bayestopt_.jscale` actually used in estimation. Thus, it looks as if this statement does nothing.
The use of `bayestopt_.mh_jscale` and `bayestopt_.jscale` as well as `options_.mh_jscale` is confusing an potentially buggy (see also http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=5072). In `dynare_estimation_1` we use
```
mh_scale_fname = [M_.fname '_optimal_mh_scale_parameter.mat'];
if exist(mh_scale_fname)
if options_.mode_compute == 0
tmp = load(mh_scale_fname,'Scale');
bayestopt_.mh_jscale = tmp.Scale;
clear tmp;
else
% remove the file if mode_compute ~= 0
delete('mh_scale_fname')
end
end
```
to read out the `mh_jscale` from a previous run of `mode_compute=6`. But this is after `dynare_estimation_init` where the `mh_jscale` seems to be translated into the `bayestopt_.jscale` actually used in estimation. Thus, it looks as if this statement does nothing.
4.5Johannes Pfeifer Johannes Pfeifer https://git.dynare.org/Dynare/dynare/-/issues/504Discuss and document the load_mh_file option2019-06-19T15:38:16ZJohannes Pfeifer Discuss and document the load_mh_file optionThe current behavior of the `load_mh_file`-option with it recomputing the mode, the Hessian, and the scale-factor by default seems counterintuitive. Given the fixed seed, one should get the same results, but there is the risk of them changing between the reloaded chain and the new elements to be added and thus having a chain with difffering proposal densities. We should at least document this behavior and potentially reload the mode-file by default. See also http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=5051
The current behavior of the `load_mh_file`-option with it recomputing the mode, the Hessian, and the scale-factor by default seems counterintuitive. Given the fixed seed, one should get the same results, but there is the risk of them changing between the reloaded chain and the new elements to be added and thus having a chain with difffering proposal densities. We should at least document this behavior and potentially reload the mode-file by default. See also http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=5051
4.5https://git.dynare.org/Dynare/dynare/-/issues/520Weibull prior distibution2019-06-19T15:38:16ZMichelJuillardWeibull prior distibutionCMR 2013 are using a Weibull prior distribution. I suggest to add it to the list of prior used by Dynare
CMR 2013 are using a Weibull prior distribution. I suggest to add it to the list of prior used by Dynare
4.5Johannes Pfeifer Johannes Pfeifer https://git.dynare.org/Dynare/dynare/-/issues/521Check treatment of covariances in DSGE-VAR2019-06-19T15:38:16ZJohannes Pfeifer Check treatment of covariances in DSGE-VARIn the wake of #392, #494, and #511 various issues with parameter updating around covariance matrices have been detected. None of these changes have been ported to `DsgeVarLikelihood` as the file still contains a TODO list in the comments that suggests that bigger changes are required.
In the wake of #392, #494, and #511 various issues with parameter updating around covariance matrices have been detected. None of these changes have been ported to `DsgeVarLikelihood` as the file still contains a TODO list in the comments that suggests that bigger changes are required.
4.5Stéphane Adjemianstepan@adjemian.euStéphane Adjemianstepan@adjemian.euhttps://git.dynare.org/Dynare/dynare/-/issues/534Discuss allowed use of endogenous variables outside of model-block2019-06-19T15:38:14ZJohannes Pfeifer Discuss allowed use of endogenous variables outside of model-blockConsider the mod-file
```
var y, c, k, a, h, b;
varexo e, u;
parameters beta, rho, alpha, delta, theta, psi, tau test;
alpha = 0.36;
rho = 0.95;
tau = 0.025;
beta = 0.99;
delta = 0.025;
psi = 0;
theta = 2.95;
phi = 0.1;
test=y*beta;
model;
c*theta*h^(1+psi)=(1-alpha)*y;
k = beta*(((exp(b)*c)/(exp(b(+1))*c(+1)))
*(exp(b(+1))*alpha*y(+1)+(1-delta)*k));
y = exp(a)*(k(-1)^alpha)*(h^(1-alpha));
k = exp(b)*(y-c)+(1-delta)*k(-1);
a = rho*a(-1)+tau*b(-1) + e;
b = tau*a(-1)+rho*b(-1) + u;
end;
initval;
y = 1.08068253095672;
c = 0.80359242014163;
h = 0.29175631001732;
k = 11.08360443260358;
a = 0;
b = 0;
e = 0;
u = 0;
end;
shocks;
var e; stderr 0.009;
var u; stderr 0.009;
var e, u = phi*0.009*0.009;
end;
stoch_simul;
```
The definition
`test=y*beta;`
results in the preprocessor plugging in for the endogenous variable `y` with its yet uncomputed steady state, i.e. 0. Users thus can create a circular problem with the steady state of `y` depending on `test` with `test` depending on `y` - and would never notice the problem, because the definition does not result in an error. Would it be possible to block this behavior? If we want to allow users to access the steady state value of endogenous variables outside of the model-block, it should be through the `steady_state`operator.
Or do I miss something that makes this behavior desirable?
Consider the mod-file
```
var y, c, k, a, h, b;
varexo e, u;
parameters beta, rho, alpha, delta, theta, psi, tau test;
alpha = 0.36;
rho = 0.95;
tau = 0.025;
beta = 0.99;
delta = 0.025;
psi = 0;
theta = 2.95;
phi = 0.1;
test=y*beta;
model;
c*theta*h^(1+psi)=(1-alpha)*y;
k = beta*(((exp(b)*c)/(exp(b(+1))*c(+1)))
*(exp(b(+1))*alpha*y(+1)+(1-delta)*k));
y = exp(a)*(k(-1)^alpha)*(h^(1-alpha));
k = exp(b)*(y-c)+(1-delta)*k(-1);
a = rho*a(-1)+tau*b(-1) + e;
b = tau*a(-1)+rho*b(-1) + u;
end;
initval;
y = 1.08068253095672;
c = 0.80359242014163;
h = 0.29175631001732;
k = 11.08360443260358;
a = 0;
b = 0;
e = 0;
u = 0;
end;
shocks;
var e; stderr 0.009;
var u; stderr 0.009;
var e, u = phi*0.009*0.009;
end;
stoch_simul;
```
The definition
`test=y*beta;`
results in the preprocessor plugging in for the endogenous variable `y` with its yet uncomputed steady state, i.e. 0. Users thus can create a circular problem with the steady state of `y` depending on `test` with `test` depending on `y` - and would never notice the problem, because the definition does not result in an error. Would it be possible to block this behavior? If we want to allow users to access the steady state value of endogenous variables outside of the model-block, it should be through the `steady_state`operator.
Or do I miss something that makes this behavior desirable?
4.5https://git.dynare.org/Dynare/dynare/-/issues/532Improve Documentation of MS-BVAR2019-06-19T15:38:14ZJohannes Pfeifer Improve Documentation of MS-BVARSee http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=5139
See http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=5139
4.5https://git.dynare.org/Dynare/dynare/-/issues/546Fix version compatibilty issues2019-06-19T15:38:14ZStéphane Adjemianstepan@adjemian.euFix version compatibilty issuesThe organization of the (global) structure `oo_` saved on disk is not constant across dynare's versions. In some situations, for instance when we need to get informations about a previous estimation as in #544, this causes a crash because needed fields do not necessarily exist if `oo_` was generated by an older version of Dynare.
The organization of the (global) structure `oo_` saved on disk is not constant across dynare's versions. In some situations, for instance when we need to get informations about a previous estimation as in #544, this causes a crash because needed fields do not necessarily exist if `oo_` was generated by an older version of Dynare.
4.5Stéphane Adjemianstepan@adjemian.euStéphane Adjemianstepan@adjemian.euhttps://git.dynare.org/Dynare/dynare/-/issues/554Check whether allowing recursive statements in steady_state_model is possible2019-06-19T15:38:14ZJohannes Pfeifer Check whether allowing recursive statements in steady_state_model is possibleI have a model in logs where I first compute the steady state for the capital and then compute the logs. However, `k=log(k);`
leads to
`ERROR: in the 'steady_state' block, variable 'k' is undefined in the declaration of variable 'k'`
although capital was computed earlier on. The preprocessor seems to disallow such recursive statements as it does not recognize that k already exists.
I have a model in logs where I first compute the steady state for the capital and then compute the logs. However, `k=log(k);`
leads to
`ERROR: in the 'steady_state' block, variable 'k' is undefined in the declaration of variable 'k'`
although capital was computed earlier on. The preprocessor seems to disallow such recursive statements as it does not recognize that k already exists.
4.5Sébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/556Change warnings and errors related to steady_state_model2019-06-19T15:38:14ZJohannes Pfeifer Change warnings and errors related to steady_state_modelEven substituting the analytical expression for k in
`k=log(k);` in a recursive definition (see #554) does not help, because it leads to
`ERROR: in the 'steady_state' block, variable 'k' is declared twice`
I would prefer to relax this last error and make it a warning. There is no reason why we should disallow overwriting previous computations.
At the same time, we do not provide a warning, if not all variables have been defined within a `steady_state_model`. Missing values are simply taken to be 0. This makes debugging of larger models hard. I would suggest to add a warning in this case.
Even substituting the analytical expression for k in
`k=log(k);` in a recursive definition (see #554) does not help, because it leads to
`ERROR: in the 'steady_state' block, variable 'k' is declared twice`
I would prefer to relax this last error and make it a warning. There is no reason why we should disallow overwriting previous computations.
At the same time, we do not provide a warning, if not all variables have been defined within a `steady_state_model`. Missing values are simply taken to be 0. This makes debugging of larger models hard. I would suggest to add a warning in this case.
4.5Sébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/566Deal with stale files that are automatically loaded in computations of e.g. e...2019-06-19T15:38:14ZJohannes Pfeifer Deal with stale files that are automatically loaded in computations of e.g. endogenous momentsIn the computation of endogenous moments, e.g. in `correlation_mc_analysis` we have statements like
```
ListOfFiles = dir([ PATH fname '_' TYPE 'Correlations*.mat']);
i1 = 1; tmp = zeros(SampleSize,1);
for file = 1:length(ListOfFiles)
```
Hence, all older files with endogenous moments are read out, regardless whether they stem from the current run or are older. This is very dangerous as those additional draws might be from different specifications. I would suggest to automatically delete those files upon running endogenous moments. Note that the same problem with the loading also occurs in identifcation and gsa and sometimes leads to crashes there as the specified number of draws does not coincide with the loaded ones.
In the computation of endogenous moments, e.g. in `correlation_mc_analysis` we have statements like
```
ListOfFiles = dir([ PATH fname '_' TYPE 'Correlations*.mat']);
i1 = 1; tmp = zeros(SampleSize,1);
for file = 1:length(ListOfFiles)
```
Hence, all older files with endogenous moments are read out, regardless whether they stem from the current run or are older. This is very dangerous as those additional draws might be from different specifications. I would suggest to automatically delete those files upon running endogenous moments. Note that the same problem with the loading also occurs in identifcation and gsa and sometimes leads to crashes there as the specified number of draws does not coincide with the loaded ones.
4.5https://git.dynare.org/Dynare/dynare/-/issues/570Compatibility with Bison 32019-06-19T15:38:12ZSébastien VillemotCompatibility with Bison 3Dynare is currently incompatible with version 3 of bison.
While fixing this, we should retain compatibility with older versions of bison (at least 2.5).
Dynare is currently incompatible with version 3 of bison.
While fixing this, we should retain compatibility with older versions of bison (at least 2.5).
4.5Sébastien VillemotSébastien Villemothttps://git.dynare.org/Dynare/dynare/-/issues/573Fix bug in interaction of diffuse filter and stoch_simul2019-06-19T15:38:12ZJohannes Pfeifer Fix bug in interaction of diffuse filter and stoch_simulSee http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=5248
See http://www.dynare.org/phpBB3/viewtopic.php?f=1&t=5248
4.5MichelJuillardMichelJuillardhttps://git.dynare.org/Dynare/dynare/-/issues/585Fix simpsa2019-06-19T15:38:12ZJohannes Pfeifer Fix simpsaSimpsa performs well with Bayesian estimation with well-defined priors. However, it is dangerous for ML estimation and Bayesian estimation with `prior_trunc=0` where `LB=-Inf` and `UB=+Inf` . In that case, simpsa will produce garbage due to line 246 using
`P(k+1,k) = LB(k)+rand*(UB(k)-LB(k));`
The infinities in the bounds will lead to NaN in the computation. However, simpsa does not crash, but will typically produce the initial point as its result with
`Change in X less than the specified tolerance (TOLX).`
Example:
```
var m P c e W R k d n l gy_obs gp_obs y dA;
varexo e_a e_m;
parameters alp bet gam mst rho psi del;
alp = 0.33;
bet = 0.99;
gam = 0.003;
mst = 1.011;
rho = 0.7;
psi = 0.787;
del = 0.02;
model;
dA = exp(gam+e_a);
log(m) = (1-rho)*log(mst) + rho*log(m(-1))+e_m;
-P/(c(+1)*P(+1)*m)+bet*P(+1)*(alp*exp(-alp*(gam+log(e(+1))))*k^(alp-1)*n(+1)^(1-alp)+(1-del)*exp(-(gam+log(e(+1)))))/(c(+2)*P(+2)*m(+1))=0;
W = l/n;
-(psi/(1-psi))*(c*P/(1-n))+l/n = 0;
R = P*(1-alp)*exp(-alp*(gam+e_a))*k(-1)^alp*n^(-alp)/W;
1/(c*P)-bet*P*(1-alp)*exp(-alp*(gam+e_a))*k(-1)^alp*n^(1-alp)/(m*l*c(+1)*P(+1)) = 0;
c+k = exp(-alp*(gam+e_a))*k(-1)^alp*n^(1-alp)+(1-del)*exp(-(gam+e_a))*k(-1);
P*c = m;
m-1+d = l;
e = exp(e_a);
y = k(-1)^alp*n^(1-alp)*exp(-alp*(gam+e_a));
gy_obs = dA*y/y(-1);
gp_obs = (P/P(-1))*m(-1)/dA;
end;
initval;
k = 6;
m = mst;
P = 2.25;
c = 0.45;
e = 1;
W = 4;
R = 1.02;
d = 0.85;
n = 0.19;
l = 0.86;
y = 0.6;
gy_obs = exp(gam);
gp_obs = exp(-gam);
dA = exp(gam);
end;
shocks;
var e_a; stderr 0.014;
var e_m; stderr 0.005;
end;
steady_state_model;
dA = exp(gam);
gst = 1/dA;
m = mst;
khst = ( (1-gst*bet*(1-del)) / (alp*gst^alp*bet) )^(1/(alp-1));
xist = ( ((khst*gst)^alp - (1-gst*(1-del))*khst)/mst )^(-1);
nust = psi*mst^2/( (1-alp)*(1-psi)*bet*gst^alp*khst^alp );
n = xist/(nust+xist);
P = xist + nust;
k = khst*n;
l = psi*mst*n/( (1-psi)*(1-n) );
c = mst/P;
d = l - mst + 1;
y = k^alp*n^(1-alp)*gst^alp;
R = mst/bet;
W = l/n;
ist = y-c;
q = 1 - d;
e = 1;
gp_obs = m/dA;
gy_obs = dA;
end;
steady;
check;
estimated_params;
//gam, normal_pdf, 0.0085, 0.003;
//mst, normal_pdf, 1.0002, 0.007;
gam, 0.003;
mst, 0.007;
end;
varobs gp_obs gy_obs;
estimation(order=1,mode_compute=10,prior_trunc=0,datafile=fsdat_simul, nobs=192, loglinear, mh_replic=2000, mh_nblocks=2, mh_jscale=0.8);
```
Simpsa performs well with Bayesian estimation with well-defined priors. However, it is dangerous for ML estimation and Bayesian estimation with `prior_trunc=0` where `LB=-Inf` and `UB=+Inf` . In that case, simpsa will produce garbage due to line 246 using
`P(k+1,k) = LB(k)+rand*(UB(k)-LB(k));`
The infinities in the bounds will lead to NaN in the computation. However, simpsa does not crash, but will typically produce the initial point as its result with
`Change in X less than the specified tolerance (TOLX).`
Example:
```
var m P c e W R k d n l gy_obs gp_obs y dA;
varexo e_a e_m;
parameters alp bet gam mst rho psi del;
alp = 0.33;
bet = 0.99;
gam = 0.003;
mst = 1.011;
rho = 0.7;
psi = 0.787;
del = 0.02;
model;
dA = exp(gam+e_a);
log(m) = (1-rho)*log(mst) + rho*log(m(-1))+e_m;
-P/(c(+1)*P(+1)*m)+bet*P(+1)*(alp*exp(-alp*(gam+log(e(+1))))*k^(alp-1)*n(+1)^(1-alp)+(1-del)*exp(-(gam+log(e(+1)))))/(c(+2)*P(+2)*m(+1))=0;
W = l/n;
-(psi/(1-psi))*(c*P/(1-n))+l/n = 0;
R = P*(1-alp)*exp(-alp*(gam+e_a))*k(-1)^alp*n^(-alp)/W;
1/(c*P)-bet*P*(1-alp)*exp(-alp*(gam+e_a))*k(-1)^alp*n^(1-alp)/(m*l*c(+1)*P(+1)) = 0;
c+k = exp(-alp*(gam+e_a))*k(-1)^alp*n^(1-alp)+(1-del)*exp(-(gam+e_a))*k(-1);
P*c = m;
m-1+d = l;
e = exp(e_a);
y = k(-1)^alp*n^(1-alp)*exp(-alp*(gam+e_a));
gy_obs = dA*y/y(-1);
gp_obs = (P/P(-1))*m(-1)/dA;
end;
initval;
k = 6;
m = mst;
P = 2.25;
c = 0.45;
e = 1;
W = 4;
R = 1.02;
d = 0.85;
n = 0.19;
l = 0.86;
y = 0.6;
gy_obs = exp(gam);
gp_obs = exp(-gam);
dA = exp(gam);
end;
shocks;
var e_a; stderr 0.014;
var e_m; stderr 0.005;
end;
steady_state_model;
dA = exp(gam);
gst = 1/dA;
m = mst;
khst = ( (1-gst*bet*(1-del)) / (alp*gst^alp*bet) )^(1/(alp-1));
xist = ( ((khst*gst)^alp - (1-gst*(1-del))*khst)/mst )^(-1);
nust = psi*mst^2/( (1-alp)*(1-psi)*bet*gst^alp*khst^alp );
n = xist/(nust+xist);
P = xist + nust;
k = khst*n;
l = psi*mst*n/( (1-psi)*(1-n) );
c = mst/P;
d = l - mst + 1;
y = k^alp*n^(1-alp)*gst^alp;
R = mst/bet;
W = l/n;
ist = y-c;
q = 1 - d;
e = 1;
gp_obs = m/dA;
gy_obs = dA;
end;
steady;
check;
estimated_params;
//gam, normal_pdf, 0.0085, 0.003;
//mst, normal_pdf, 1.0002, 0.007;
gam, 0.003;
mst, 0.007;
end;
varobs gp_obs gy_obs;
estimation(order=1,mode_compute=10,prior_trunc=0,datafile=fsdat_simul, nobs=192, loglinear, mh_replic=2000, mh_nblocks=2, mh_jscale=0.8);
```
4.5