Non-greedy async optimization #374
Conversation
trieste/acquisition/rule.py
Outdated
| if state is None: | ||
| state = AsynchronousRuleState(None) | ||
|
|
||
| state = state.subtract_points(datasets[OBJECTIVE].query_points) |
There was a problem hiding this comment.
I'm not sure this covers the corner case where we have duplicated observations. In that case we do want to remove the pending points that have just been queried but not the pending points that have duplicates in the past.
There was a problem hiding this comment.
why would we want to keep duplicate points? and why would duplicates arise in the first place?
There was a problem hiding this comment.
if you have noise, it can make sense to choose to sample twice the same point. In some cases, the maximiser of the acquisition function can be an existing point.
I think that making sure that we don't remove more points than the newly acquired ones should do the trick. E.g. if you have 3 identical pending points and you get 1 back, it doesn't matter which pending point you're substracting but you should not remove more than one.
There was a problem hiding this comment.
this is now implemented, but turned out to be very hard to do efficiently, so i suspect current implementation may trigger tf graph evaluation prematurely. If anyone has better ideas on how to implement it, please suggest
|
Yes, the notebook is in process. I'd prefer to make a separate PR for it, to make these PRs reasonably sized. Smaller and focused PRs are easier to review. |
This PR contains implementation for a second rule for async optimization, conveniently named AsynchronousOptimization. This isn't expected to be high-performant (and we warn users in docs about it), but it gives access to non-greedy batch functions in async mode.
Although not a part of the PR, new rule was verified to run in the async notebook in addition to all tests.
Plus there is a bit of a clean up for blunders I made in #366 .