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,
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 marco.ratto@jrc.ec.europa.eu writes:
- 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?
- 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,
Hi Sebastien,
thanks a lot. I will check and tell you Marco
On 1/20/2012 6:16 PM, Sébastien Villemot wrote:
Marco Rattomarco.ratto@jrc.ec.europa.eu writes:
- 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?
- 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 -
Michel Juillard -
Sébastien Villemot