I’m occasionally encountering the message
Warning: non-finite fitness range when using the CMA-ES algorithm, and would like to ask about whether this can be suppressed — or, alternatively, how it should be addressed.
Here is the simplest example I was able to condense the model originally producing this message down to:
var x ppi int;
parameters sig bet kap deli delpi delpi_b delx delx_b alph1 alph2 alph3;
sig = 2;
bet = 0.99;
kap = 103/300;
alph1 = 1;
alph2 = 0.5;
alph3 = 0.1;
int = deli*int(-1) + delpi_b*ppi(-1) + delx_b*x(-1) + delpi*ppi + delx*x;
x = x(+1) - 1/sig*(int - ppi(+1));
ppi = bet*ppi(+1) + kap*x + nuu;
var nuu; stderr 1;
delpi = -2.890122072233906;
delx = -0.305456448924854;
deli = 0.950714306409916;
delpi_b = 6.684053447700940;
delx_b = -2.035314463153560;
osr_params deli delpi_b delx_b delpi delx;
deli, 0, 1;
osr(opt_algo = 9, nograph);
A few remarks: the starting values for the policy parameters were randomly drawn, and the actual model file uses several different sets of starting values to identify the overall best OSR. The chosen policy parameters resulting from this particular set of starting values are not optimal (which is why I’m otherwise using several sets of starting values). Finally, setting Dynare’s seed is important, and other seeds may or may not reproduce this issue.
As always, thank you very much in advance for your advice and your help, and have a nice weekend.
This is a typical warning for the optimizer when you hit infeasible regions. It’s nothing to worry about if it only happens occasionally.
Thanks again for taking the time to reply — alright, I’ll not worry about the warning then (it’s only certain starting values that trigger this, and I’m computing optimal rules several times using different starting values for robustness anyway).
I’d still like to turn off this warning if possible: each call to
osr() in the code I’m working with where this is encountered produces many of these warnings, and optimal rules are calculated for many different (thousands) of values of the deep parameters, so it becomes difficult to locate other console output among all those warnings.
Since MATLAB already includes a mechanism for enabling/disabling specific warnings, allowing users to do this would be as easy as including a warning ID in the call to
warning(), i.e. change line 974 in
warning('Non-finite fitness range');
warning('Dynare:CMAES:nonFiniteFitnessRange', 'Non-finite fitness range');
or something similar so that users could then simply do
osr(). (Of course, it would be best to simultaneously add identifiers to all Dynare warnings.)
May I suggest this for a future Dynare release? If you believe this would be a worthwhile change I could attempt to prepare a patch as well.
All the best & thanks again!
Wonderful, thank you.
I’ve created an account on git.dynare.org; once it’s been approved I can fork the project, add warning IDs and submit a pull request for the main repo.
Alternatively, please let me know if there is a different preferred way to submit patches for the project.
Dear Prof. Pfeifer,
I had the same warning. “Warning: Non-finite fitness range” I was wondering if it is because I did not add the lower and upper bound for the parameter estimation. Based on my knowlwdge, it is not necessary to add boundary for estimation.
Having no bounds increases the likelihood of the warning, but you should be safe to ignore the warning in any case.
Thank you, Prof. Pfeifer, for your reply.