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.