Super! We have greatly diminished the number of failures on the tests. I tried to see why gsa/ls2003.mod was failing under Octave but can't understand. The test works when dynare is called interactively, but fails when called via run_test_octave.m. It looks as if the interaction of try and global estim_params_ is creating a problem in this case. It would be great if somebody finds out what is going on.
Best
Michel
Hi Michel,
I am not at work today, but I think I know what is happening. I remember I noted that on octave gsa crashes if I do not type explicitly
clear global;
before running it after a previous dynare session.
There is a check in dynare_sensitivity for the existence of estim_params_ which triggers or not dynare_estimation_init. Without clear global there is still a variable estim_init_ in the octave workspace that skips estimaton init and therefore the routine crashes. I will have to check if this check is really necessary and perhaps put an explicit initialization flag there.
Still, this clear global issue seems to be something to be aware of and fix for octave sessions?
best Marco
On Sun, 30 Oct 2011 18:08:42 +0100, Michel Juillard michel.juillard@mjui.fr wrote:
Super! We have greatly diminished the number of failures on the tests. I tried to see why gsa/ls2003.mod was failing under Octave but can't understand. The test works when dynare is called interactively, but fails when called via run_test_octave.m. It looks as if the interaction of try and global estim_params_ is creating a problem in this case. It would be great if somebody finds out what is going on.
Best
Michel
Dev mailing list Dev@dynare.org https://www.dynare.org/cgi-bin/mailman/listinfo/dev
Hi Marco,
the test in dynare_sensitivity depends on bayestopt_ being empty, but bayestopt_ was not initialized in global_initialization.m
I added it and will commit tonight. I think it will do it.
All the best,
Michel
On 10/31/2011 9:30 AM, rattoma wrote:
Hi Michel,
I am not at work today, but I think I know what is happening. I remember I noted that on octave gsa crashes if I do not type explicitly
clear global;
before running it after a previous dynare session.
There is a check in dynare_sensitivity for the existence of estim_params_ which triggers or not dynare_estimation_init. Without clear global there is still a variable estim_init_ in the octave workspace that skips estimaton init and therefore the routine crashes. I will have to check if this check is really necessary and perhaps put an explicit initialization flag there.
Still, this clear global issue seems to be something to be aware of and fix for octave sessions?
best Marco
On Sun, 30 Oct 2011 18:08:42 +0100, Michel Juillard michel.juillard@mjui.fr wrote:
Super! We have greatly diminished the number of failures on the tests. I tried to see why gsa/ls2003.mod was failing under Octave but can't understand. The test works when dynare is called interactively, but fails when called via run_test_octave.m. It looks as if the interaction of try and global estim_params_ is creating a problem in this case. It would be great if somebody finds out what is going on.
Best
Michel
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
Thanks a lot Marco
On Mon, 31 Oct 2011 17:24:45 +0100, Michel Juillard michel.juillard@mjui.fr wrote:
Hi Marco,
the test in dynare_sensitivity depends on bayestopt_ being empty, but bayestopt_ was not initialized in global_initialization.m
I added it and will commit tonight. I think it will do it.
All the best,
Michel
On 10/31/2011 9:30 AM, rattoma wrote:
Hi Michel,
I am not at work today, but I think I know what is happening. I remember I noted that on octave gsa crashes if I do not type
explicitly
clear global;
before running it after a previous dynare session.
There is a check in dynare_sensitivity for the existence of
estim_params_
which triggers or not dynare_estimation_init. Without clear global there is still a variable estim_init_ in the octave workspace that skips estimaton init and therefore the routine crashes. I will have to check if this check is really necessary and perhaps put
an
explicit initialization flag there.
Still, this clear global issue seems to be something to be aware of and fix for octave sessions?
best Marco
On Sun, 30 Oct 2011 18:08:42 +0100, Michel Juillard michel.juillard@mjui.fr wrote:
Super! We have greatly diminished the number of failures on the tests. I tried to see why gsa/ls2003.mod was failing under Octave but can't understand. The test works when dynare is called interactively, but fails when called via run_test_octave.m. It looks as if the interaction of try and global estim_params_ is creating a problem in this case. It would be great if somebody finds out what is going on.
Best
Michel
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
Dev mailing list Dev@dynare.org https://www.dynare.org/cgi-bin/mailman/listinfo/dev
Dear All,
I would like to discuss some issues around the best way to include analytic scores and hessian in dsgelikelihood.m
1) extension to all KF routines: Currently, analytic derivations done only for the standard KF (stationary multivariate KF). This is done in a separate routine, however is this a good approach? This would imply that all KF routines will have a replica with analytic derivatives and all changes / bug fixes in the base KF routines will have to be ported to the ones with analytic derivations. So, I would like to consider the possibility to include extra options to all current KF routines with "if" statements triggering the analytic computations. This will have the cost of evaluating and "if" at every recursion in the KF.
2) using analytic derivatives in estimation: using analytic scores and/or hessian in optimization is now an option at hand. In this case, I would like to discuss the issue about the output arguments to dsgelikelihood. Currently the first output if fval, then a full list of output flags and dynare options, and finally we added scores and hessian. In an optimization framework, it would be convenient to have 1st and 2nd derivatives just after fval. I see two options for doing that: a) change the list of output arguments: we have to take care of changing all calls to dsgelikelihood across dynare; b) when analytic derivatives are triggered, the fval output argument becomes a cell array with the following entries: {LIK, SCORES, HESSIAN}. In no analytic derivation is triggered, fval remains as it is now. In this case, nothing will be changed when the standard numerical gradient and hessian are used, but will make calls easier when analytic scores/hessian are used.
what do you think?
best Marco