Hi all,
Following a discussion regarding option names that we had here on Friday and then again by mail on Monday, we wanted to open it to further input as there was disagreement between the few of us that are at Chevaleret.
On Friday, we discussed renaming the options that begin with mh_ to begin with mcmc_. Basically, we want to deprecate the mh_ options all the while supporting them for backwards compatibility. We are all in agreement about this and hence opened ticket #644.
On Monday, I had the idea to simply drop mcmc_ completely. In other words, mcmc_replic and mcmc_drop would become, more simply, replic and drop. In the preprocessor we would create rules that would store these in an options_.mcmc substructure, such as options_.mcmc.replic and options_.mcmc.drop.
I spoke with Sebastien about this and his preference is not to make this change, the argument being that 1) by keeping the mcmc_ prefix, it’s more clear to the user what the options mean and 2) that in Dynare, currently, options are global and hence this changes the default behavior as the “replic” option in stoch_simul would not be global with the “replic” option in estimation (i.e., there are two different rules in the preprocessor that match “replic”, depending on which command it is passed to).
With regards to 1), my view was that the options are understood within the context of the command they’re passed to and though the mcmc_ prefix makes it explicit, it’s not ultimately necessary as people get option names and their meanings from the manual. Further, with respect to 2), it seems that Dynare is in the process of transitioning towards non-global options; this has already happened with ms-sbvar, and is happening with estimation, so this change would be along the lines of making that transition.
Via email on Monday, Stephane agreed with my point of view. Hence, Sebastien wanted to open the discussion to more input so we can come to a final decision about this.
Best, Houtan
Hi,
I don't think it is something we can get into one option at the time. There are many good reasons to redesign the options, but it should be done systematically. In this particular instance, it is not entirely true that the command context is sufficient to define "replic". In the estimation context, if we are considering non-linear estimation, there is both the number of replications for MCMC and the number of replications for simulating the resulting IRF's. If we consider redoing the options--I'm in favor of it-- a first job would be to identify all options, and the commands where they are used, on a wiki page. It is almost copy and paste from the Bison file. One should also indicate the options that have different meaning in different context and the options that have similar meaning but different names in different contexts (I'm thinking about the tolerance levels and the maximum number of iterations)
Best
Michel
Houtan Bastani writes:
Hi all,
Following a discussion regarding option names that we had here on Friday and then again by mail on Monday, we wanted to open it to further input as there was disagreement between the few of us that are at Chevaleret.
On Friday, we discussed renaming the options that begin with mh_ to begin with mcmc_. Basically, we want to deprecate the mh_ options all the while supporting them for backwards compatibility. We are all in agreement about this and hence opened ticket #644.
On Monday, I had the idea to simply drop mcmc_ completely. In other words, mcmc_replic and mcmc_drop would become, more simply, replic and drop. In the preprocessor we would create rules that would store these in an options_.mcmc substructure, such as options_.mcmc.replic and options_.mcmc.drop.
I spoke with Sebastien about this and his preference is not to make this change, the argument being that 1) by keeping the mcmc_ prefix, it’s more clear to the user what the options mean and 2) that in Dynare, currently, options are global and hence this changes the default behavior as the “replic” option in stoch_simul would not be global with the “replic” option in estimation (i.e., there are two different rules in the preprocessor that match “replic”, depending on which command it is passed to).
With regards to 1), my view was that the options are understood within the context of the command they’re passed to and though the mcmc_ prefix makes it explicit, it’s not ultimately necessary as people get option names and their meanings from the manual. Further, with respect to 2), it seems that Dynare is in the process of transitioning towards non-global options; this has already happened with ms-sbvar, and is happening with estimation, so this change would be along the lines of making that transition.
Via email on Monday, Stephane agreed with my point of view. Hence, Sebastien wanted to open the discussion to more input so we can come to a final decision about this.
Best, Houtan _______________________________________________ Dev mailing list Dev@dynare.org https://www.dynare.org/cgi-bin/mailman/listinfo/dev
-
Houtan Bastani -
Michel Juillard