persistent variables
I'm worried about the use of persistent variables in Dynare. In several instances, they are only re-initialized if the variable is empty, meaning the first time that the function is used at the beginning of a session or after "clear all" This behavior is wrong if the function with persistent variables is used twice in different contexts in the same *.mod file (identification_analysis and estimation, for example, or two successive estimations). Also, it creates hard to understand errors when debugging with option noclearall Because, the initialization must sometimes take place far away from the function itself, it is even hard to check whether there is proper initialization or not. I suggest 1) to unify the interface to initialize the persistent variables: either passing additional arguments, or calling the function without any input arguments 2) write in the header of a function using persistent variable which functions are calling it and where initialization takes place. 3) See if using classes with could avoid the use of persistent variables What do you think? Best Michel
Michel Juillard <michel.juillard@mjui.fr> writes:
I'm worried about the use of persistent variables in Dynare. In several instances, they are only re-initialized if the variable is empty, meaning the first time that the function is used at the beginning of a session or after "clear all"
This behavior is wrong if the function with persistent variables is used twice in different contexts in the same *.mod file (identification_analysis and estimation, for example, or two successive estimations). Also, it creates hard to understand errors when debugging with option noclearall
This problem has already been reported in ticket #83: https://www.dynare.org/trac/ticket/83 Note that I am personally very strongly against the use of persistent variables. They are essentially equivalent to global variables, and therefore create the same very-hard-to-track-down bugs. The core of the problem is that when you use persistent (or global) variables, there is no guarantee that calling two times the same function with the same input arguments will give the same output. This is the opposite of functional programming, which is for me the most natural paradigm, especially for people with a mathematical background. I therefore think that we should set the goal of removing all persistent variables, as removing all global variables is also a goal. Of course, removing all of them is probably not possible because of various resource constraints, but we should at least avoid introducing new ones. Best, -- Sébastien Villemot Researcher in Economics & Debian Maintainer http://www.dynare.org/sebastien Phone: +33-1-40-77-49-90 - GPG Key: 4096R/381A7594
Dear Sebastien, I would like to discuss two problems that I would like to fix around identification and sensitivity analysis preprocessor. 1) You may remember the issue about overly large params_derivs files descending from elaborated parameterizations. This specially affects the second order derivs w.r.t. model params. I just had an exchange with Jasper Linde who is using a model where he uses pond syntax to define a complicated parametrization, which then implies such a problem. I think for the next 4.2.5 dynare bug fix release we could simply drop second order derivs w.r.t. parameters in the official distribution, since such derivatives are not used for the moment (this feature maybe useful in the future when I will have the time to preceed further with some diagnostics for global identification). This would make the release of dynare totally compatible with such complicated cases. 2) In the case of sensitivity analysis, on the other hand, there is a problem when models have unit roots. We should allow for 4.3 version to add the option kalman_algo to dynare_sensitivity and identification. In such a case, the qz_criterium would be kept 1+1.e-6. Otherwise, the call to dynare_estimation_init, with the default kalman_algo=1, resets qz_criterium to 1-1.e-6 and the blanchard kahn are always violated for any parameter value in the Monte Carlo search for stability mapping, when the model has unit roots. how do you think? thanks a lot for your assistance best wishes Marco -- Marco Ratto, (http://easu.jrc.ec.europa.eu/), Joint Research Centre The European Commission, TP 361, 21027 ISPRA(VA), ITALY Tel: +39 0332 78 5639 Fax: +39 0332 78 5733 marco.ratto@jrc.ec.europa.eu
Marco Ratto <marco.ratto@jrc.ec.europa.eu> writes:
1) You may remember the issue about overly large params_derivs files descending from elaborated parameterizations. This specially affects the second order derivs w.r.t. model params. I just had an exchange with Jasper Linde who is using a model where he uses pond syntax to define a complicated parametrization, which then implies such a problem.
I think for the next 4.2.5 dynare bug fix release we could simply drop second order derivs w.r.t. parameters in the official distribution, since such derivatives are not used for the moment (this feature maybe useful in the future when I will have the time to preceed further with some diagnostics for global identification). This would make the release of dynare totally compatible with such complicated cases.
I guess you are referring to ticket #172: https://www.dynare.org/trac/ticket/172 I have just realized that we were not computing temporary terms for 2nd deriv of residuals and jacobian wrt to params (rpp and gpp) and for 1st deriv of hessian wrt params (hpp). I pushed a fix for this in master and 4.2. Tell me if that improves your problem. If it does not, I will do what you asked for. Do you want me to also remove hpp from the output of the dynamic file, or only rpp and gpp?
2) In the case of sensitivity analysis, on the other hand, there is a problem when models have unit roots. We should allow for 4.3 version to add the option kalman_algo to dynare_sensitivity and identification. In such a case, the qz_criterium would be kept 1+1.e-6. Otherwise, the call to dynare_estimation_init, with the default kalman_algo=1, resets qz_criterium to 1-1.e-6 and the blanchard kahn are always violated for any parameter value in the Monte Carlo search for stability mapping, when the model has unit roots.
I added this option to the preprocessor and ref. manual. I leave you the job to add the necessary logic in MATLAB (including setting the default for qz_criterium). Best, -- Sébastien Villemot Researcher in Economics & Debian Maintainer http://www.dynare.org/sebastien Phone: +33-1-40-77-49-90 - GPG Key: 4096R/381A7594
Hi Sebastien, thanks a lot. I will check and tell you Marco On 1/20/2012 6:16 PM, Sébastien Villemot wrote:
Marco Ratto<marco.ratto@jrc.ec.europa.eu> writes:
1) You may remember the issue about overly large params_derivs files descending from elaborated parameterizations. This specially affects the second order derivs w.r.t. model params. I just had an exchange with Jasper Linde who is using a model where he uses pond syntax to define a complicated parametrization, which then implies such a problem.
I think for the next 4.2.5 dynare bug fix release we could simply drop second order derivs w.r.t. parameters in the official distribution, since such derivatives are not used for the moment (this feature maybe useful in the future when I will have the time to preceed further with some diagnostics for global identification). This would make the release of dynare totally compatible with such complicated cases.
I guess you are referring to ticket #172: https://www.dynare.org/trac/ticket/172
I have just realized that we were not computing temporary terms for 2nd deriv of residuals and jacobian wrt to params (rpp and gpp) and for 1st deriv of hessian wrt params (hpp).
I pushed a fix for this in master and 4.2. Tell me if that improves your problem.
If it does not, I will do what you asked for. Do you want me to also remove hpp from the output of the dynamic file, or only rpp and gpp?
2) In the case of sensitivity analysis, on the other hand, there is a problem when models have unit roots. We should allow for 4.3 version to add the option kalman_algo to dynare_sensitivity and identification. In such a case, the qz_criterium would be kept 1+1.e-6. Otherwise, the call to dynare_estimation_init, with the default kalman_algo=1, resets qz_criterium to 1-1.e-6 and the blanchard kahn are always violated for any parameter value in the Monte Carlo search for stability mapping, when the model has unit roots.
I added this option to the preprocessor and ref. manual. I leave you the job to add the necessary logic in MATLAB (including setting the default for qz_criterium).
Best,
-- Marco Ratto, (http://easu.jrc.ec.europa.eu/), Joint Research Centre The European Commission, TP 361, 21027 ISPRA(VA), ITALY Tel: +39 0332 78 5639 Fax: +39 0332 78 5733 marco.ratto@jrc.ec.europa.eu
participants (3)
-
Marco Ratto -
Michel Juillard -
Sébastien Villemot