estimated parameter interface
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 -- Michel Juillard
-----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-----
The new estimation syntax is outlined here: http://www.dynare.org/DynareWiki/NewEstimation I don't recall the specific syntax I created for Dan and Tao as I haven't looked at that code for a while now (can't seem to find a wiki page about it either). Michel may know more about this code now as he's closer to it. Speaking with Sebastien, apparently there's no fixed release date for 4.4 so, I'd be happy to revise the front end once the wiki page is set. Best, Houtan On 22 Sep 2013, at 22:48, Stéphane Adjemian <stepan@dynare.org> wrote:
-----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-----
_______________________________________________ Dev mailing list Dev@dynare.org https://www.dynare.org/cgi-bin/mailman/listinfo/dev
Le lundi 23 septembre 2013 à 16:01 +0200, Houtan Bastani a écrit :
Speaking with Sebastien, apparently there's no fixed release date for 4.4 so, I'd be happy to revise the front end once the wiki page is set.
There is no fixed date for the release, but it should happen as soon as possible. Also, my understanding is that the new estimation syntax was not intended to be made public for 4.4 (at least it is not on the NewFeatures wiki page, and the github issue is not scheduled for 4.4), so this development is basically unrelated to the upcoming release. -- Sébastien Villemot Researcher in Economics Dynare developer http://www.dynare.org/sebastien
The issue is that in that interface, the specification of regime is a sub-option of prior. That is one of the thing that I would like to change. Best Michel Houtan Bastani writes:
The new estimation syntax is outlined here: http://www.dynare.org/DynareWiki/NewEstimation
I don't recall the specific syntax I created for Dan and Tao as I haven't looked at that code for a while now (can't seem to find a wiki page about it either). Michel may know more about this code now as he's closer to it.
Speaking with Sebastien, apparently there's no fixed release date for 4.4 so, I'd be happy to revise the front end once the wiki page is set.
Best, Houtan
On 22 Sep 2013, at 22:48, Stéphane Adjemian <stepan@dynare.org> wrote:
-----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-----
_______________________________________________ Dev mailing list Dev@dynare.org https://www.dynare.org/cgi-bin/mailman/listinfo/dev
_______________________________________________ Dev mailing list Dev@dynare.org https://www.dynare.org/cgi-bin/mailman/listinfo/dev
-- Michel Juillard
participants (4)
-
Houtan Bastani -
Michel Juillard -
Stéphane Adjemian -
Sébastien Villemot