You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
Currently, only fixed number of iteration can be set to the optimizer. However, a convergence criteria would be useful.
Describe the solution you'd like
By using a convergence criteria, a maximum number of steps OR the convergence criteria could be used to stop the iteration (whichever happens first). The reason why the iteration stopped should be available after the execution.
Are you able and willing to implement this feature yourself and open a pull request?
Yes, I can provide this feature.
If anyone can do this issue, that would be great, however, I'm also fine with doing it myself in a form of PR.
you're not the first to bring this up and I can see the appeal.
In my personal opinion, since such things can be performed by using suggest-evaluate-register (#373) instead of optimizer.maximizer(), I would prefer to keep the API clean. I would be interested in what other people have to say though.
How would you determine that the optimization procedure has converged?
I wouldn't mind adding optional convergence criteria as an argument that can be passed at instantiation.
At the moment, there is only really one - number of iterations. But we could also add:
If x iterations have occured without at least y improvement (y should probably include both relative and absolute tolerance?)
I wouldn't mind adding optional convergence criteria as an argument that can be passed at instantiation. At the moment, there is only really one - number of iterations. But we could also add:
If x iterations have occured without at least y improvement (y should probably include both relative and absolute tolerance?)
if a solution is found better than some value
others?
From my project experiences, here are some termination criteria:
input variables(X) tolerance based termination
objective function value tolerance based termination
Is it possible to pass stop criteria such as stop_value or real_tol to the "optimizer.maximizer()" instead of doing it manually with suggest-evaluate-register?
Is it possible to pass stop criteria such as stop_value or real_tol to the "optimizer.maximizer()" instead of doing it manually with suggest-evaluate-register?
I'd get a lot out of this so happy to have a look at implementing it. Personally I've manually implemented terminating based on a number of iterations without any improvement so would find this quite useful. I've got a work in progress branch with some very scrappy changes that adds a target value as termination criteria, branch here: https://github.com/cballam/BayesianOptimization/tree/convergence_criteria
I'll spend some time to implement the "if X iterations passed without Y improvement" criteria and look at the time-based one. The time-based version would be challenging to fit with user expectations with the save/load functionality so I am a little unsure how to handle it, but personally would also find it quite useful.
I do agree with keeping the interfaces clean and this will probably end up being the most challenging part of any implementation. Open to any suggestions on this
Life got in the way for a while, but I've cleaned up the single commit I've made to look at adding this functionality and made a MR for feedback/review. Open to any feedback people have the time to give as I am certain the code is not as good as it could be. I have just looked at it enough to not see a clear way to improve it #591
Activity
t-muser commentedon Nov 23, 2022
Hi @gaborantal,
you're not the first to bring this up and I can see the appeal.
In my personal opinion, since such things can be performed by using suggest-evaluate-register (#373) instead of
optimizer.maximizer(), I would prefer to keep the API clean. I would be interested in what other people have to say though.How would you determine that the optimization procedure has converged?
bwheelz36 commentedon Nov 24, 2022
I wouldn't mind adding optional convergence criteria as an argument that can be passed at instantiation.
At the moment, there is only really one - number of iterations. But we could also add:
xiterations have occured without at leastyimprovement (y should probably include both relative and absolute tolerance?)some valuegaborantal commentedon Nov 24, 2022
This is exactly what we need. However, your other mentioned option also looks great, and might be useful.
jacktang commentedon Jun 7, 2024
From my project experiences, here are some termination criteria:
and we compose some terminations if possible
amir-shahbazi23 commentedon Jun 12, 2025
Is it possible to pass stop criteria such as stop_value or real_tol to the "optimizer.maximizer()" instead of doing it manually with suggest-evaluate-register?
t-muser commentedon Jun 13, 2025
@amir-shahbazi23
as of now, no
cballam commentedon Jul 12, 2025
I'd get a lot out of this so happy to have a look at implementing it. Personally I've manually implemented terminating based on a number of iterations without any improvement so would find this quite useful. I've got a work in progress branch with some very scrappy changes that adds a target value as termination criteria, branch here: https://github.com/cballam/BayesianOptimization/tree/convergence_criteria
I'll spend some time to implement the "if X iterations passed without Y improvement" criteria and look at the time-based one. The time-based version would be challenging to fit with user expectations with the save/load functionality so I am a little unsure how to handle it, but personally would also find it quite useful.
I do agree with keeping the interfaces clean and this will probably end up being the most challenging part of any implementation. Open to any suggestions on this
cballam commentedon Sep 27, 2025
Life got in the way for a while, but I've cleaned up the single commit I've made to look at adding this functionality and made a MR for feedback/review. Open to any feedback people have the time to give as I am certain the code is not as good as it could be. I have just looked at it enough to not see a clear way to improve it #591