-----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.
1) 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 2) 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)
3) 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.
4) 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.
5) 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.
6) 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iF4EAREIAAYFAlI/V5kACgkQrQOaeEU5AZcpRAEAvwAd8M/8urAAyJaff7SwEGma HgObpryUON9/Nd9kf94BAIG6AvB/1RFVAsNFqlT9FAKGuBMjyX0J5/HEZ3ehNgkk =XjCy -----END PGP SIGNATURE-----