I am fine with all the suggestions. I only have one question: What do you mean with a "modifier of moments_varendo"? It may be we already had this discussion with the option conditional_variance_decomposition.
As far as I know, we still allow for options not having any effect if the overarching option is not set. For example, if moments_varendo is false, no moments will be computed even if he explicitly specified ar or conditional_variance_decomposition. That's why I thought it should trigger moments_varendo. It always confuses users if he specifies an option and nothing happens because he forgot to specify a different option. For conditional_variance_decomposition we solved the issue by putting in the manual
"Note that this option requires the option moments_varendo to be specified."
But I am not sure, this is the best solution. If would prefer a more specific option like conditional_variance_decomposition to trigger the bigger option that encompasses it. Imagine someone running a MCMC estimation that took a long time. He specified ar and conditional_variance_decomposition but forgot moments_varendo. In this case, Dynare will simply do nothing. The user will then have to go through all the hassle to try to use the existing MCMC results to finally trigger the computation of what he wanted.
-------- Johannes Pfeifer Haußerstr. 29 72076 Tübingen Tel.: +49-(0)7071-6396184 Mobil: +49-(0)170-6936820 jpfeifer@gmx.de
-----Ursprüngliche Nachricht----- Von: dev-bounces@dynare.org [mailto:dev-bounces@dynare.org] Im Auftrag von Michel Juillard Gesendet: Mittwoch, 8. August 2012 17:28 An: List for Dynare developers Betreff: Re: [DynareDev] [Trac] #276: Add ar-option to estimation command
I'm surprised that the options of stoch_simul are not included in the options for estimation. I think it was the case in a far away past.
Looking at the options for stoch_simul, I realize that several deal with displaying options and other things not useful for estimation, but I think it would be better to keep in DynareBison.yy a subset of options relative to the computation of the solution and related statistics in one set that is then used for for stoch_simul and for estimation. Johannes remark on 'ar' but we should also provide, for example, for the posterior distribution of moments for HP-filtered variables. I don't think it is currently possible. This requires closer examination.
However, I disagree with two aspects of Johannes proposal: 'ar' should not trigger 'moments_varendo', it should be thought as a modifier of 'moments_varendo'. Having one name of the option for stoch_simul and one name for estimation, follows in fact from the desire to keep the options local to one command rather than global as it is mostly the case now. I'm convinced that we should move to local options, but if we start to give different names for options that do the same thing in different contexts, we will never advance on local options. (The case of 'replic' is different. There, we were using the same option name for two different things, done in stoch_simul: the number of replications to be used when simulating data and the number of replications to be used for computing IRFs ar order 2 and 3. I think that we right to introduce two different names in this case)
What do you think?
Best
Michel
On 08/08/2012 05:05 PM, Trac Dynare wrote:
#276: Add ar-option to estimation command --------------------------+----------------------- Reporter: jpfeifer | Owner: sebastien Type: enhancement | Status: new Priority: minor | Milestone: 5.0 Component: Preprocessor | Version: 4.3.0 Keywords: | --------------------------+----------------------- Currently, the ar-option is only allowed in {{{stoch_simul}}}. Its value then also tranfers to the computation of moments in {{{compute_moments_varendo.m}}}. We should explicitly implement ar in estimation. If specified, it should also trigger the
{{{moments_varendo}}}
option. This avoids setting {{{options_.ar}}} before the estimation command. Maybe we should split {{{options_.ar}}} into {{{options_.ar}}} for stoch_simul and {{{options_.var_endo_ar}}} for estimation in order
for
one command not to affect the computations from the other one as is currently the case.
_______________________________________________ Dev mailing list Dev@dynare.org https://www.dynare.org/cgi-bin/mailman/listinfo/dev