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

Multi trust regions #773

Merged
merged 41 commits into from
Aug 25, 2023
Merged

Multi trust regions #773

merged 41 commits into from
Aug 25, 2023

Conversation

khurram-ghani
Copy link
Collaborator

@khurram-ghani khurram-ghani commented Jul 26, 2023

Related issue(s)/PRs: None
Related branch: victor/trustregions

Summary

This PR adds support for multi-trust-regions acquisition rule; based-on and refactored from branch victor/trustregions.

The main classes are:

  • CollectionSearchSpace
    • A new abstract class representing search spaces made up of a collection of sub-spaces.
  • TaggedMultiSearchSpace
    • A concrete implementation of CollectionSearchSpace for collections where all sub-spaces have the same dimensionality. This is the class used for current trust-region rules.
  • TaggedProductSearchSpace
    • The existing product search space class now inherits from CollectionSearchSpace.
  • UpdatableTrustRegion
    • A new abstract class representing search spaces that can be updated or reinitialised.
  • BatchTrustRegion
    • A new abstract class for trust region acquisition rules.
  • SingleObjectiveTrustRegionBox
    • A concrete implementation of UpdatableTrustRegion for the algorithm implemented in victor/trustregions.
  • BatchTrustRegionBox
    • A concrete implementation of BatchTrustRegion for the algorithm implemented in victor/trustregions.

The intention is that whenever a new trust region algorithm is implemented, in most cases, it would be sufficient to simply sub-class UpdatableTrustRegion and BatchTrustRegion.

Question: since SingleObjectiveTrustRegionBox/BatchTrustRegionBox is a specific trust-regions implementation, should it be moved to either a separate file or perhaps to a notebook? Is it generally useful?
Answer: yes these are useful and should be kept with the rules for now.

An example notebook will be added in a follow-on PR.

Fully backwards compatible: yes

PR checklist

  • The quality checks are all passing
  • The bug case / new feature is covered by tests
  • Any new features are well-documented (in docstrings or notebooks)

Copy link
Collaborator

@hstojic hstojic left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

did a pass, few minor comments for now - but still thinking about the code in rule.py file, trying to make up my mind about updatable class - are there efficiency gains with that?

trieste/space.py Outdated Show resolved Hide resolved
docs/notebooks/multi_trust_region.pct.py Outdated Show resolved Hide resolved
@khurram-ghani
Copy link
Collaborator Author

trying to make up my mind about updatable class - are there efficiency gains with that?

@hstojic
There aren't computation efficiency gains. This is about good design patterns (encapsulation); what is easy for developers to understand and maintain. In my opinion, having a separate update-able class makes it clear what it does and keeps most of the code self contained. Only when something applies to multiple regions (e.g. maybe_reinitialise_subspaces), it exists in the rule iteself.

trieste/acquisition/rule.py Outdated Show resolved Hide resolved
trieste/acquisition/rule.py Outdated Show resolved Hide resolved
trieste/acquisition/rule.py Outdated Show resolved Hide resolved
trieste/acquisition/rule.py Outdated Show resolved Hide resolved
trieste/acquisition/rule.py Outdated Show resolved Hide resolved
trieste/acquisition/rule.py Show resolved Hide resolved
trieste/acquisition/rule.py Outdated Show resolved Hide resolved
trieste/acquisition/rule.py Show resolved Hide resolved
trieste/acquisition/rule.py Outdated Show resolved Hide resolved
trieste/acquisition/rule.py Outdated Show resolved Hide resolved
Copy link
Collaborator

@hstojic hstojic left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

did another round, focusing on the changes in rule

* Use generic search space type for MultiTrustRegionBox
* Add some private methods to TrustRegionBox
* Add kwargs to reinitialize/update
* Use American spelling
* Move helper function to utils
Copy link
Collaborator

@uri-granta uri-granta left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(a few minor initial comments while I was reminding myself of the space and optimizer work; will look at the rule next)

trieste/space.py Outdated Show resolved Hide resolved
trieste/space.py Outdated Show resolved Hide resolved
trieste/space.py Outdated Show resolved Hide resolved
trieste/space.py Outdated Show resolved Hide resolved
trieste/acquisition/utils.py Outdated Show resolved Hide resolved
trieste/acquisition/optimizer.py Show resolved Hide resolved
Copy link
Collaborator

@uri-granta uri-granta left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(Some initial rule comments in case you want to respond/chat. Will carry on looking.)

trieste/acquisition/rule.py Outdated Show resolved Hide resolved
trieste/acquisition/rule.py Outdated Show resolved Hide resolved
trieste/acquisition/rule.py Outdated Show resolved Hide resolved
trieste/acquisition/rule.py Outdated Show resolved Hide resolved
* Rename reinitialize to initialize
* Replace get_single_model_and_dataset with generic get_value_for_tag;
  plus update unit tests
* Add unit tests for and change get_unique_points_mask implementation as
  previous version erroneously identified some points as duplicates
Plus revert addition of kwargs
@khurram-ghani khurram-ghani marked this pull request as ready for review August 9, 2023 09:13
@khurram-ghani khurram-ghani mentioned this pull request Aug 9, 2023
3 tasks
Copy link
Collaborator

@uri-granta uri-granta left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A few minor comments, but generally happy from an engineering persepctive.

trieste/space.py Show resolved Hide resolved
trieste/space.py Show resolved Hide resolved
trieste/acquisition/rule.py Show resolved Hide resolved
trieste/acquisition/rule.py Show resolved Hide resolved
trieste/acquisition/rule.py Outdated Show resolved Hide resolved
Copy link
Collaborator

@hstojic hstojic left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

looks good, I have left a bunch of comments, but no major point I think - I'm mostly curious how it would look like when starting to use the new division between the updatable search space and rule class itself, in the sense of subclassing them to create new variants

tests/unit/acquisition/test_optimizer.py Show resolved Hide resolved
trieste/acquisition/utils.py Outdated Show resolved Hide resolved
trieste/space.py Show resolved Hide resolved
trieste/space.py Show resolved Hide resolved
trieste/space.py Show resolved Hide resolved
trieste/acquisition/rule.py Show resolved Hide resolved
trieste/acquisition/rule.py Outdated Show resolved Hide resolved
trieste/acquisition/rule.py Outdated Show resolved Hide resolved
trieste/acquisition/rule.py Outdated Show resolved Hide resolved
trieste/acquisition/utils.py Show resolved Hide resolved
@khurram-ghani khurram-ghani merged commit 93f44b3 into develop Aug 25, 2023
12 checks passed
@khurram-ghani khurram-ghani deleted the khurram/trustregions branch August 25, 2023 13:02
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

Successfully merging this pull request may close these issues.

4 participants