-
Notifications
You must be signed in to change notification settings - Fork 415
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
Enabling candidate generation with both non_linear_constraints
and fixed_features
#1912
Conversation
Codecov Report
@@ Coverage Diff @@
## main #1912 +/- ##
=========================================
Coverage 100.00% 100.00%
=========================================
Files 173 173
Lines 15232 15290 +58
=========================================
+ Hits 15232 15290 +58
📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah I think this makes sense. If there are multiple fixed features it's going to be slower than optimizing over the reduced domain since the optimizer needs to (i) identify the fixed features and (ii) SLSQP scales pretty poorly with the problem dimension anyway.
But that's probably fine for now (maybe add this comment in code for future reference?
tensor([0.4887, 0.5063])
This doesn't seem to be the right output? Should be 3dim with the third feature fixed to 0.5?
nonlinear_inequality_constraints=[nlc1, nlc2, nlc3, nlc4], | ||
batch_initial_conditions=batch_initial_conditions, | ||
num_restarts=num_restarts, | ||
fixed_features={0: 2}, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm so with this setup this test may pass even if fixing the features doesn't work (given that it only narrows this to a specific solution of the previous solution set). Can you use a different value here? I might also make sense to use a different mock acquisition function so that the optimizer is unique...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I will have a deeper look to the test. All this mocking is sometimes a bit hard for me to understand ;)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think there is actually any mocking going on here - it's just that mock_acq_function
is a SquaredAcquisitionFunction
rather than a true acquisition function.
If you don't want to change that, one thing you could do would be to just replace one of the constraints to result in a different optimum / optimizer.
Test failure seems unrelated I'll take a look at that |
Co-authored-by: Max Balandat <Balandat@users.noreply.github.com>
…nto non_linear_and_fixed
Hi @Balandat, I implemented now also the solution using the reduced domain. Which one do you prefer? Best, Johannes |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks great, just a couple of minor style nits. Thanks for putting this up!
@Balandat, I incorporated your changes and added another test which was still missing (from my perspective). From my side, this is now ready for merge. |
Great, thanks you. I'll pull it in and merge it. |
@Balandat has imported this pull request. If you are a Meta employee, you can view this diff on Phabricator. |
This was solved by #1919, should pass upon re-running the tests. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for adding this @jduerholt! Mainly left cosmetic suggestions that will aid readability, as well as completed type signatures.
Last, could you rename the PR something a little more descriptive like "Enabling candidate generation with both non_linear_constraints
and fixed_features
"? This will make it easier to understand what's going on when browsing the commit history on a high level.
constraints: Optional[List[Callable]], | ||
fixed_features: Dict[int, float], | ||
dimension: int, | ||
) -> Optional[List[Callable]]: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Two subjective suggestions to make this quicker to parse:
- How about
_gen_nonlin_constraints_of_variable_features
? Could apply same convention to the linear case below. (cc @Balandat) - Could you add a doc-string here, something like "Given a dictionary of
fixed_features
, returns a list of non-linear constraints on the variable (non-fixed) features."
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I added a docsting. Concerning renaming: should I do it, or should it be done in a seperate PR for both methods (nonlinear and linear) to keep it consistent?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you! If you're up for it, you can do both in this commit. The only mentions of _generate_unfixed_lin_constraints
are in:
generation/utils.py
,optim/parameter_constraints.py
, andtest/optim/parameter_constraints.py
.
A quick search and replace in these files should do it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, but do you really prefer the new name? What do you do not like about _generate_unfixed_lin_constraints
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But ofc, I can do it ;)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
_generate_unfixed_(non)lin_constraints
makes it sound like the constraints are "unfixed", whereas it is the features that are. But let's keep it then, especially since the docstring makes it clear now. Thanks for adding it!
Co-authored-by: Sebastian Ament <56886879+SebastianAment@users.noreply.github.com>
non_linear_constraints
and fixed_features
@SebastianAment has imported this pull request. If you are a Meta employee, you can view this diff on Phabricator. |
@Balandat has imported this pull request. If you are a Meta employee, you can view this diff on Phabricator. |
Motivation
This PR adds the possibility to use
fixed_features
in combination withnonlinear_inequality_constraints
as discussed in issue #1904.@Balandat: concerning the solution that you suggested: I think it is much easier as the
f_np_wrapper
is also used for the nonlinear constraints:botorch/botorch/generation/gen.py
Line 224 in 38e2027
fix_features
is already applied there:botorch/botorch/generation/gen.py
Line 189 in 38e2027
So no need for another wrapper, or?
A wrapper function would be only needed if one wants to have the possibility to use the nonlinear constraints also with the reduced domain, then one would need a method, which takes the reduced X as input and augments it with the fixed features.
Here is some example code, that shows that it works:
Have you read the Contributing Guidelines on pull requests?
Yes.
Test Plan
Unit tests.