Remove pending_observations argument from gen and gen_single_trial
#4723
+289
−311
Conversation
This file contains hidden or 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
added 4 commits
December 29, 2025 09:26
Summary: When `gen_single_trial` does not call `gen`, we have a few problems, in order of importance: 1. Forgetting to specify `pending_observations` to `gen_single_trial` will result in no `pending_observations` use. This is different from the behavior in the main `gen`, so it's a huge gotcha and could already be causing silent bugs. 2. Unnecessary bifurcation, meaning that more behaviors like 1) could encroach in the future. 3. Repeated operations. Reviewed By: saitcakmak Differential Revision: D80174582 Privacy Context Container: L1307644
Summary: Long-overdue diff to stop applying input constructors in a manual way that defeats their purpose (if each is applied through a helper, what's the point of keeping them in a mapping from the name of the arg they are going to construct, to a callable that constructs it?) This diff: 1. Moves behavior related to injection of "disabled parameters" in the search space, from input constructor (where it's not even guaranteed to apply since that input constructor isn't always used), to generation node (for now; proposed move to adapter is in D89779057 –– let's consider alternatives on that diff, too), with an underlying utility moved to `SearchSpace` to be co-located with the rest of the disabled parameter logic. 2. Reaps `GenerationStrategy.DEFAULT_N`, which was actually unused (or used in one place but always left at its default of 1, only complicating things). D89772029 will deal with this better, with a top-level concurrency setting added via an `ExperimentDesign` object. 3. Applies input constructors generically, in a loop, instead of via helpers per input constructor purpose. This ends up removing a bunch of duplicate logic that lived at different layers within. Reviewed By: saitcakmak Differential Revision: D80175141 Privacy Context Container: L1307644
…#4703) Summary: The dedicated `__eq__` was needed to override a previous gotcha: dataclasses have an `__eq__` defined and it might not do what you want it to once your dataclass gets succifiently complex (e.g. if it also inherits from Ax `SortableBase` [used for storage], it's `__eq__` won't apply bc the one from `dataclasses` will take precedence). This isn't needed anymore though. Reviewed By: saitcakmak Differential Revision: D80175518 Privacy Context Container: L1307644
Summary: Curious what folks think. I think we in practice never actually need to specify a custom setting for this arg and it's easy to forget to pass it. We can streamline this behavior by defaulting to always extract it within the GS. Reviewed By: saitcakmak Differential Revision: D80174601 Privacy Context Container: L1307644
|
@lena-kashtelyan has exported this pull request. If you are a Meta employee, you can view the originating Diff in D80174601. |
meta-cla
bot
added
the
CLA Signed
|
This pull request has been merged in 2556735. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
Summary: Curious what folks think. I think we in practice never actually need to specify a custom setting for this arg and it's easy to forget to pass it. We can streamline this behavior by defaulting to always extract it within the GS.
Reviewed By: saitcakmak
Differential Revision:
D80174601
Privacy Context Container: L1307644