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

Intervenors, and an issue with the abstract-final pattern #20

Open
mlprt opened this issue Feb 26, 2024 · 1 comment
Open

Intervenors, and an issue with the abstract-final pattern #20

mlprt opened this issue Feb 26, 2024 · 1 comment
Labels
wontfix This will not be worked on

Comments

@mlprt
Copy link
Owner

mlprt commented Feb 26, 2024

As mentioned in #19, intervention operations are prepended to the existing stages of a model's state operations. The intervention operations are defined by inserting AbstractIntervenor objects into the intervenors: Mapping[Optional[str], Sequence[AbstractIntervenor]] field of any AbstractStagedModel.

Currently, every subclass of AbstractStagedModel needs to implement that field. This is annoying: the field is generally just an empty dict that is later filled up with stuff, so it is always implemented in the same way. Developers are expected to repeat themselves.

We could avoid this by implementing intervenors directly in AbstractStagedModel, but this would violate the abstract-final pattern. We haven't been enforcing the pattern by subclassing equinox.Module with strict=True, yet.

Is there a way to avoid implementing intervenors in the base class?

There are a few other places this same issue appears in Feedbax.

  • the intervene field, in all final subclasses of feedbax.task.AbstractTaskTrialSpec;
  • the intervention_specs and intervention_specs_validation fields in all final subclasses of AbstractTask;
  • the label field in all final subclasses of AbstractIntervenor—when we use schedule_intervenor, this is used to assign a unique label to each intervenor among all the intervenors belonging to a model, so that it can be matched up with its trial-by-trial parameters, which are specified as a flat PyTree (ModelInput and passing intervenor parameters to submodels #12). The user generally does not have to assign to this field.
@mlprt mlprt changed the title Intervenors, and issues with the abstract-final pattern Intervenors, and an issue with the abstract-final pattern Mar 4, 2024
@mlprt mlprt pinned this issue Mar 4, 2024
@mlprt
Copy link
Owner Author

mlprt commented Jul 26, 2024

This should be simplified/obviated if we replace the staged model approach with a DAG approach (#28), so I'm tagging this issue as "won't fix".

In particular, intervenors will have a similar status as any other leaf modules.

@mlprt mlprt added the wontfix This will not be worked on label Jul 26, 2024
@mlprt mlprt unpinned this issue Jul 26, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
wontfix This will not be worked on
Projects
None yet
Development

No branches or pull requests

1 participant