-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
Hi Michel,
There is already something for declaring regimes in the new estimation interface. As I am not concerned by this I did not try, but this is mentionned on the wikipage and I am sure that Houtan has more to say about this. He added the possibility to declare regimes as a provision for Dan and Tao's codes.
Reading your email, I realize that we do not have the possibilty to declare breaks (or regimes) for calibrated parameters (obviously we may associate zero prior variance to such parameter).
Regarding your propositions I would prefer to have the possibilty to name the regimes (not just numbers) and also I would find more natural do define the regime just after the parameter name, ie:
alpha.regime(1).prior(...)
instead of
alpha.prior(...).regime(1)
The same for the calibrated parameters.
I am not sure we still need the estimated_params block. Priors can be defined outside of any block. We just need a block to declare the list of parameters to be estimated. Something like
estimated_parameters alpha gamma beta ;
where alpha beta and gamma are already defined in the parameters block. Doing so we do not not have to add a new field for maximum likelihood (or another for gmm and yet another for indirect inference, ...).
Best, Stéphane.
On 21/09/2013 18:05, Michel Juillard wrote:
Following on my visit to JRC/Ispra, I started looking at the possibility to use Dynare as a front end for DMM
http://http://ipsc.jrc.ec.europa.eu/fileadmin/repository/sfa/finepro/softwar...
A program for Bayesian estimation of dynamic mixture models developped by G. Fiorentini, C. Planas and A. Rossi.
Doing so, I found some difficulties with the new estimation interface that we had discussed and implemented recently. I don't know how much freedom do we have still to modify elements of this interface.
- regime is an attribute of a parameter that doesn't belong to its
prior: a parameter can be calibrated with different values in
different regimes
- I suggest to introduce instead a regime() keyword at the same logical
level as prior() as well as a value() keyword. So as to have alpha.prior(......).regime(1) alpha.prior(......).regime(2)
or, for calibrated paramters
beta.value(0).regime(1) beta.value(1.5).regime(2)
- of course, it would be odd, to list calibrated parameters in the
estimated_params block, but, maybe handy, to authorize it to help people who alternate between calibrating and estimating a given parameter in the model construction phase. I suggest to put the dot syntax for parameter specification in a parameters block that would be an alternative to the parameters line.
- replacing the estimated_params block by a parameter block. All
parameters with prior specification would be estimated. We need a keyword equivalent to prior() for maximum likelhood, maybe maxlik() with sub-options for initial values and possible bounds.
- We should allow for chained dot expressions as above or several line
with different elements specified on different lines as long as it is not ambiguous or contradictory with a previous specification.
- When a parameter has been specified with a regime keyword, it should
always be referred to with a regime() keyword except if the new specification can be valid for all keywords.
I think that such changes would be also useful for MS-dsge models. Is it still possible to introduce them at low cost? If that the case, I would work on a more developed specification on a Wiki page.
Best
- -- Stéphane Adjemian