Skip to content

Convergence criteria #381

Open
Open

Description

@gaborantal

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.

Activity

  1. t-muser commented on Nov 23, 2022

    @t-muser
    Member

    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?

  2. bwheelz36 commented on Nov 24, 2022

    @bwheelz36
    Collaborator

    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?
  3. gaborantal commented on Nov 24, 2022

    @gaborantal
    Author
    * If `x` iterations have occured without at least `y` improvement (y should probably include both relative and absolute tolerance?)
    

    This is exactly what we need. However, your other mentioned option also looks great, and might be useful.

  4. jacktang commented on Jun 7, 2024

    @jacktang

    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
    • max iteration / evaluation
    • time based termination
    • target value based termination

    and we compose some terminations if possible

  5. amir-shahbazi23 commented on Jun 12, 2025

    @amir-shahbazi23

    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?

  6. t-muser commented on Jun 13, 2025

    @t-muser
    Member

    @amir-shahbazi23

    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?

    as of now, no

  7. cballam commented on Jul 12, 2025

    @cballam

    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

  8. cballam commented on Sep 27, 2025

    @cballam

    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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions