#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.
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.
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
Michel Juillard michel.juillard@mjui.fr writes:
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?
I agree with adding relevant options of stoch_simul to estimation, and with moving towards local options.
As a side note, I notice that we have a tendency to discuss trac tickets via email on the list rather than within trac. The bad consequence is that in the future, when looking at the ticket on the web interface, there will be no reference to the discussion that has taken place on the list; this can potentially lead to the forgetting of important information.
A possible solution would be to move away from Trac and use a bug tracking system (BTS) that is mostly controlled by email. The obvious candidate is debbugs, the Debian BTS, that could be easily installed on kirikou. Since it is controlled by email, it is probably less user-friendly, but I don't expect that to be a problem since we are all skilled developers :) It has a web interface, but only for reading information, not for modifying it. I would personally be in favour of such a change, since I prefer using my email client than my web browser.
#276: Add ar-option to estimation command ---------------------------+----------------------- Reporter: jpfeifer | Owner: sebastien Type: enhancement | Status: closed Priority: minor | Milestone: 5.0 Component: Preprocessor | Version: 4.3.0 Resolution: fixed | Keywords: ---------------------------+----------------------- Changes (by sebastien):
* status: new => closed * resolution: => fixed
Comment:
Option ar added to estimation in 90c15ec. The moments_varendo option is not automatically triggered (would be too confusing). There seems to be another bug with the autocorrelation function, this is being investigated.
-
Johannes Pfeifer -
Michel Juillard -
Sébastien Villemot -
Trac Dynare