Comp Rep Transition Point #278
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
AdrianSosic
commented
Jun 25, 2024
AdrianSosic
commented
Jun 25, 2024
AdrianSosic
force-pushed
the
refactor/surrogates/transition_point
branch
from
ed2a23b to
f2f5370
Compare
|
@AdrianSosic I guess you shouldnt rebase this branch but the target branch? otherwise i see the last main commits also always in this PR :/ |
Scienfitz
reviewed
Jun 25, 2024
AdrianSosic
force-pushed
the
refactor/surrogates/transition_point
branch
2 times, most recently
from
041dbd6 to
33ac341
Compare
AdrianSosic
force-pushed
the
refactor/surrogates/transition_point
branch
from
33ac341 to
49350a3
Compare
AVHopp
reviewed
Jun 26, 2024
AVHopp
reviewed
Jun 27, 2024
Scienfitz
reviewed
Jun 28, 2024
|
will wait with approval for other PR and rebase |
AdrianSosic
force-pushed
the
refactor/surrogates/transition_point
branch
4 times, most recently
from
0dec698 to
7669528
Compare
AdrianSosic
force-pushed
the
refactor/surrogates/transition_point
branch
from
7669528 to
78e3938
Compare
Merged
AdrianSosic
added a commit
that referenced
this pull request
Aug 29, 2024
Completes the surrogate factoring, which extended over #278, #309, #315, #325, #337. ### Most important changes * The transition point from experimental to computational representation has been moved from the recommender to the surrogate. From an architecture/responsibility perspective, this is reasonable since the recommend should not have to bother about algorithmic/computational details. * The desired consequence is that public `Surrogate` methods like `posterior` and `fit` can now operate on dataframes in experimental representation, meaning they can also be exposed directly to the user. * The new posterior methods now all return a general `Posterior` object instead of implicitly assuming Gaussian distributions. This paves the way for arbitrary surrogate extensions, such as Bernoulli/Categorical surrogates, etc. At the moment, this introduces an explicit coupling to botorch, which is fine because botorch remains a core dependency and the only backend used for complex surrogate modeling. In the future, this can be further abstracted by introducing our own `Posterior` class. * The `Surrogate` layout has been refined such that the extracted `SurrogateProtocol`, which now defines the formal interface for all surrogates, imposes minimal requirements to the user. * Scaling has been completely redesigned, offering the possibility to configure input/output scaling down to the level of individual parameters and targets. The configuration is currently class-specific, but can be extended to allow surrogate instance specific rules in the future.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR is a first step toward a refactored
Surrogatelayout:exp_rep-to-comp_reptransition point into the surrogates, which now become responsible for handling the transformation and can do it in whatever way they need it (which will also simplify scaling later on).exp_rep) and do not need to worry about transformations.