Conversation
jpenn2023
requested review from
AVHopp,
AdrianSosic and
Scienfitz
as code owners
jpenn2023
force-pushed
the
dev-mfbo-main-surrogate-models
branch
from
d062293 to
8ed0f2a
Compare
AdrianSosic
force-pushed
the
dev-mfbo-main-surrogate-models
branch
from
ccac1f8 to
178772a
Compare
AVHopp
left a comment
AVHopp
left a comment
There was a problem hiding this comment.
Some comments on everything but the multi_fidelity.py file, as I guess that we will discuss this today in a bit more detail.
jpenn2023
force-pushed
the
dev-mfbo-main-surrogate-models
branch
from
2e64082 to
8e8547b
Compare
|
Hey @jpenn2023, I just wanted to have a look at your PR but then noticed that something went wrong with your rebase. I know you asked me about the weird diff shown on Github (and yes, that is generally still a problem), but it turns out that your diff is wrong for a different reason – namely because you somehow rebased your commits together with an entire bunch of other commits 😬 Can you quickly fix it and ping me once ready for review? |
jpenn2023
force-pushed
the
dev-mfbo-main-surrogate-models
branch
from
d96cf75 to
2c513b0
Compare
AdrianSosic
force-pushed
the
dev-mfbo-main-surrogate-models
branch
from
2c513b0 to
754d5da
Compare
AdrianSosic
force-pushed
the
dev-mfbo-main-surrogate-models
branch
from
754d5da to
563b86a
Compare
AdrianSosic
force-pushed
the
dev-mfbo-main-surrogate-models
branch
from
563b86a to
88db97f
Compare
|
Hey @jpenn2023, have a look, this should now give you a clean picture of your PR content, right? |
Hi @AdrianSosic. Yes, this view looks right to me. |
Scienfitz
left a comment
Scienfitz
left a comment
There was a problem hiding this comment.
my biggest question is why the concepts of TL and MF are now deedply intertwined by using a single searchspace property for combining them isntead of two properties characterizing the searchspaces task / fidelity character
AVHopp
left a comment
AVHopp
left a comment
There was a problem hiding this comment.
Some more thoughts from my end
baybe/searchspace/core.py
Outdated
| NumericalDiscreteFidelityParameter, | ||
| ) | ||
|
|
||
| n_task_like_parameters = sum( |
There was a problem hiding this comment.
Also, shouldn't we be able to fully get this by using the properties? There literally are different properties for checking the number task and fidelity dimensions, so I would assume that we do not need to recalculate this here - unless this would mean to change how those are calculated (as we currently technically only check if there is at least one).
baybe/searchspace/core.py
Outdated
| NumericalDiscreteFidelityParameter, | ||
| ) | ||
|
|
||
| n_task_like_parameters = sum( |
There was a problem hiding this comment.
Also, if we go through the self.parameters, couldn't we simply count how many different occurrences of the different parameter types we find? The code does multiple iterations over the full self.parameters, it would be fully sufficient to this once, count the occurrences of the individual parameters and then act based on those numbers.
|
@jpenn2023 it seems like the continuous search space example is currently failing which is why the doc building does not run (just FYI as reading the doc building error logs can be a bit annoying) |
There was a problem hiding this comment.
I've found several comments that were marked as resolved without them actually being addressed. Please ONLY resolve comments when the changes are actually visible and have been pushed. Also, it would be great if you could give context when resolving a comment. For example, I asked an explicit question at one point and the comment was just being resolved without providing an answer and without changing the corresponding code.
EDIT: Whoopsie, this was on me. Ignore :)
| @override | ||
| @staticmethod | ||
| def _make_target_scaler_factory() -> type[OutcomeTransform] | None: | ||
| # For GPs, we let botorch handle the scaling. See [Scaling Workaround] above. |
There was a problem hiding this comment.
Please no copy-paste comments, there is no Scaling Workaround above.
| input_transform=input_transform, | ||
| outcome_transform=outcome_transform, | ||
| data_fidelities=None | ||
| if context.fidelity_idx is None |
There was a problem hiding this comment.
Why is this if-else necessary? Shouldn't the validation at the top guarantee this already or is this necessary for type checking only?
| "spaces with multiple task parameters." | ||
| ) | ||
|
|
||
| def fidelity_type(self) -> SearchSpaceFidelityType: |
There was a problem hiding this comment.
Shouldn't this also be a property?
| @property | ||
| def n_fidelities(self) -> int: | ||
| """The number of fidelities encoded in the search space.""" | ||
| # See TODO [16932] above |
There was a problem hiding this comment.
Please remove the number and directly refer to the corresponding function, that is, have it as # TODO: See comment in n_tasks property
| """Column index of the fidelity parameter in computational representation.""" | ||
| if (fidelity_param := self._fidelity_parameter) is None: | ||
| return None | ||
| # See TODO [11611] above |
There was a problem hiding this comment.
Please remove the number and directly refer to the corresponding function, that is, have it as # TODO: See comment in tasks_idx property
4 participants
Adding multi-fidelity properties for the SearchSpace class and multi-fidelity Gaussian process classes with the required fidelity kernels.