WIP: Preparations for method of moments estimation: command
I finished a first draft for GMM (up to third order using the pruned state space) and SMM (up to 3rd order with pruning and to any k-order without pruning) in Dynare and need some preparations in the preprocessor. It is on my branch moment_estimation and I will merge it soon.
Stuff I already did in this merge request
First, due to some work by @JohannesPfeifer, the preprocessor currently already has commands called gmm_estimation
and smm_estimation
. As discussed in dynare#1724 (closed), we should merge these into one command called method_of_moments(OPTIONS)
. This is the goal of this merge request. Also, method_of_moments(OPTIONS)
behaves similar to identification
in the sense that it creates its own structure with options.
Further to Dos
I have no idea how to implement the following:
-
make the fields mom_method
anddatafile
required -
if order > 2 then we need to make sure that k_order_solver is selected and all files created (similar to stoch_simul and identification) -
method of moments order should be independent of the order set by other functions, eg stoch_simul or identification
Once this has been merged, I will merge the first draft of the method of moments toolbox.
Merge request reports
Activity
added help wanted macroprocessor labels
Thanks for this WIP.
Here are a few comments on the 3 items for which you need help:
- in order to require fields
mom_method
anddatafile
, you can have a look at the implementation inParsingDriver::trend_component_model()
andParsingDriver::var_model()
- on the fact that order > 2 should imply
k_order_solver
: it looks like you already implemented that inMethodOfMomentsStatement::checkPass()
. Or do I miss something? - I don’t understand your third item. You say that the order should be independent, but then your pseudo-code suggests the opposite. In any case, I don’t really see how independence could be achieved, because the preprocessor can only compute a given order.
- in order to require fields
- Resolved by Willi Mutschler
added 18 commits
-
dcb12bb9...479c2c02 - 16 commits from branch
Dynare:master
- aec93bd9 - Merged gmm_estimation and smm_estimation into moment_estimation
- f2e09e40 - mom: use mom_estimation_present and make mom_order/datafile necessary
-
dcb12bb9...479c2c02 - 16 commits from branch
I think it is ready to be merged. But keep in mind that this is my first attempt at changing stuff in the preprocessor (even though most stuff is simply copy and paste), so glad for any feedback ;-)
Edited by Willi Mutschler@JohannesPfeifer currently does code review of my method of moments toolbox draft. So let's wait for him before merging this.
added 1 commit
- 51bef1a5 - Rename mom_steps to additional_optimizer_steps
added 11 commits
-
51bef1a5...c4351166 - 6 commits from branch
Dynare:master
- ca0ff0c4 - Merged gmm_estimation and smm_estimation into moment_estimation
- 7310ecc1 - mom: use mom_estimation_present and make mom_order/datafile necessary
- 10f94691 - Remove explicit from MethodOfMoments
- faeb8886 - Add centered_moments back to MethodOfMoments
- 6673a601 - Rename mom_steps to additional_optimizer_steps
Toggle commit list-
51bef1a5...c4351166 - 6 commits from branch
3846 o_smm_seed : SEED EQUAL INT_NUMBER { driver.option_num("smm.seed", $3); }; 3847 o_smm_bounded_shock_support : BOUNDED_SHOCK_SUPPORT { driver.option_num("smm.bounded_support", "true"); }; 3783 o_mom_method : MOM_METHOD EQUAL GMM 3784 { driver.option_str("mom_method", $3); } 3785 | MOM_METHOD EQUAL SMM 3786 { driver.option_str("mom_method", $3); } 3787 ; 3788 o_centered_moments : CENTERED_MOMENTS { driver.option_num("centered_moments", "true"); }; 3789 o_penalized_estimator : PENALIZED_ESTIMATOR { driver.option_num("penalized_estimator", "true"); }; 3790 o_verbose : VERBOSE { driver.option_num("verbose", "true"); }; 3791 3792 o_simulation_multiple : SIMULATION_MULTIPLE EQUAL INT_NUMBER { driver.option_num("simulation_multiple", $3); }; 3793 o_bounded_shock_support : BOUNDED_SHOCK_SUPPORT { driver.option_num("bounded_shock_support", "true"); }; 3794 o_seed : SEED EQUAL INT_NUMBER { driver.option_num("seed", $3); }; 3795 o_tolf : TOLF EQUAL non_negative_number { driver.option_num("dynatol.f", $3); }; 3796 o_tolx : TOLX EQUAL non_negative_number { driver.option_num("dynatol.x", $3); }; @wmutschl Why do you even need
dynatol.f
anddynatol.x
? They are forperfect_foresight
onlydynatol.f
is needed if you have a steady state file inevaluate_steady_state_file.m
,dynatol.x
is needed to compute numerical standard errors (for instance as we will reusefjaco.m
).Edited by Willi Mutschler
assigned to @sebastien
added 6 commits
-
59bda04d - 1 commit from branch
Dynare:master
- be46fe78 - Merged gmm_estimation and smm_estimation into moment_estimation
- 746a6bed - mom: use mom_estimation_present and make mom_order/datafile necessary
- 7cf30dd2 - Remove explicit from MethodOfMoments
- f4c04674 - Add centered_moments back to MethodOfMoments
- 3d4976f8 - Rename mom_steps to additional_optimizer_steps
Toggle commit list-
59bda04d - 1 commit from branch
@sebastien We would need a preprocessor option that takes a comma-separated array of strings within round brackets, e.g.
weighting_matrix=(optimal,identity,test.mat)
and translates it into a cell array:
weighting_matrix={'optimal';`identity`;`test.mat`}
I don't think we have something similar yet to base this on. The closest thing may be
posterior_sampler_options
in terms of parsing. But that one takesname,value
-pairs. Any hints?o_optim
is also close to what you have in mind, but it also accepts name/value pairs.But what you want is possible to implement, it just needs a bit of craft.
Another possibility, maybe more consistent with existing syntaxes, would be to introduce a new command that takes a list of options, and specifically dedicated to declaring this weighting matrix. See e.g.
compilation_setup
, or evenperfect_foresight_setup
.@sebastien: Is there a way to skip the initialization of
options_mom_ = struct()
in the driver?@sebastien To be more precise, there is a design issue here. The
method_of_moments
-command has its ownoptions_
-list that we initialize to be empty in order to prevent inheritance from previous options-settings. But that also implies that the user cannot manually set options directly be e.g. writingoptions_mom_.weighting_matrix={'optimal';'identity';'test.mat'};
. The question is how to deal with that. My preference would be not to initialize the option as empty and test in Matlab whether it already exists and then provide a warning about the consequences. What do you think?I will close this and we will continue in !23 (merged)