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

cheap-to-evaluate constraint #537

Closed
satrialoka opened this issue Mar 25, 2022 · 2 comments · Fixed by #656, #660 or #664
Closed

cheap-to-evaluate constraint #537

satrialoka opened this issue Mar 25, 2022 · 2 comments · Fixed by #656, #660 or #664
Labels
enhancement New feature or request

Comments

@satrialoka
Copy link
Collaborator

Describe the feature you'd like
I want functionality for using cheap-to-evaluate-constraint in Trieste directly without modeling it using a GP.

Is your feature request related to a problem? Please describe.
Sometimes we had a closed-form formula of our constraint which will be faster and more accurate to use as it is rather than model it as a GP.

Describe alternatives you've considered
One of the approaches is utilizing the scipy optimizer such as SLSQP(gradient-based) and COBYLA(gradient-free), by feeding the cheap constraint directly to the acquisition function optimizer.

Additional context
Currently, Trieste 0.10.0 only supports LBFGSB optimizer, it might be nice if we can change the choice of optimizer by using optimizer args without modifying the acquisition optimizer function.

I was using this approach on the older version of Trieste, the problem that might arise is the starting point of the MC stage in the acquisition optimizer will be unfeasible cheap-constraint wise. I was removing the unfeasible points using tf.boolean_mask to tackle this problem.

Other concern is, the cheap-constraint might be too strict and makes the BO not exploring some areas which might be important for the GPs of the objectives and expensive constraints.

@satrialoka satrialoka assigned hstojic and unassigned hstojic Mar 25, 2022
@uri-granta uri-granta added the enhancement New feature or request label Jun 28, 2022
@uri-granta
Copy link
Collaborator

Explicit constraints are now supported (#656, #660, #664) as described at https://secondmind-labs.github.io/trieste/develop/notebooks/explicit_constraints.html. Is it ok to close this ticket?

@satrialoka
Copy link
Collaborator Author

Nice! Sure!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
3 participants