Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Early termination and iteration skipping. #328

Open
nickanthony-dgl opened this issue May 10, 2023 · 1 comment
Open

Early termination and iteration skipping. #328

nickanthony-dgl opened this issue May 10, 2023 · 1 comment

Comments

@nickanthony-dgl
Copy link

Is there a recommended way to have an objective function request early termination of the optimization. I know that I could probably just throw an exception but I am wondering if there is a better way that still allows Limbo to perform any needed clean up before ending.

Additionally I am wondering if there is a way to have the objective function request that the optimizer skip a certain iteration. For example, my objective function has some inputs which cannot be evaluated but I am not able to predict ahead of time what those illegal inputs are. Is there a way for the objective function to avoid evaluating that input but still have the optimizer try testing other points?

@costashatz
Copy link
Member

Is there a recommended way to have an objective function request early termination of the optimization. I know that I could probably just throw an exception but I am wondering if there is a better way that still allows Limbo to perform any needed clean up before ending.

It's exactly the reason that we have the StoppingCriteria (see here for the already implemented ones). You can create a new one that gets triggered whenever you wish: e.g. the objective function can write to a global variable and the criteria can read this variable and decide when to stop.

Additionally I am wondering if there is a way to have the objective function request that the optimizer skip a certain iteration. For example, my objective function has some inputs which cannot be evaluated but I am not able to predict ahead of time what those illegal inputs are. Is there a way for the objective function to avoid evaluating that input but still have the optimizer try testing other points?

We do not have this, but it'd be a nice feature. Although there needs to be some considerations: i.e., if you just skip the iteration and the problem is deterministic, the acquisition function might return exactly the same point to evaluate.

Do you know any good references on how to handle those cases? Like BO with ``negative'' samples?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants