Refactor Modifiers

[TimothyWillard]

Describe your changes.

• Add pydantic representations for distributions with a sample method for usage here. Ideally would also be used in likelihood, but should reserve this for a follow up issue+PR.
• Add Gamma, Beta, and Weibull distributions, [Feature request]: Gamma and Weibull Distribution support #573.
• Add unit tests for existing gempyor.NPI functionality, to build a baseline of existing behavior as needed.
• nb: moving from "reduce" to "apply modifiers"
• Add apply abstract method to ModifierABC taking arguments parameter_name, parameter, method and using SinglePeriodModifier as an example implement reduce. nb: see helpers.py for ex. Should drop into:

  flepiMoP/flepimop/gempyor_pkg/src/gempyor/parameters.py

  Lines 309 to 336 in 00a262d

  	def parameters_reduce(self, p_draw: ndarray, npi: object) -> ndarray:
  	"""
  	Params reduced according to the NPI provided.
  	Args:
  	p_draw: A numpy array of shape (`npar`, `n_days`, `nsubpops`) like that
  	returned by `parameters_quick_draw`.
  	npi: An NPI object describing the parameter reduction to perform.
  	Returns:
  	An array the same shape as `p_draw` with the prescribed reductions
  	performed.
  	"""
  	p_reduced = copy.deepcopy(p_draw)
  	if npi is not None:
  	for idx, pn in enumerate(self.pnames):
  	npi_val = NPI.reduce_parameter(
  	parameter=p_draw[idx],
  	modification=npi.getReduction(pn.lower()),
  	method=self.pdata[pn]["stacked_modifier_method"],
  	)
  	p_reduced[idx] = npi_val
  	if "rolling_mean_windows" in self.pdata[pn]:
  	p_reduced[idx] = utils.rolling_mean_pad(
  	data=npi_val, window=self.pdata[pn]["rolling_mean_windows"]
  	)
  	return p_reduced

  .
• Add apply_dataframe method to ModifierABC that is a wrapper around apply.
• Add ModifiersCollection using pydantic.BaseModel to represent the 'outcome_modifiers' and 'seir_modifiers' sections in config files. Pretty minimal, scenarios: list[str] and modifiers: list[Modifier].
• Refactor ModifiersCollection to have a scenarios_map attribute (needs better name or maybe some rethinking, ideally would be called scenarios but that attribute is already occupied) that is dict[str, list[str]] to represent "stacked modifiers". Requires adding a model validator to ModifiersCollection to rewrite StackedModifiers to this to maintain backwards compatibility.
• Add reduce (now .apply()) method to ModifiersCollection that implements similar logic to the current StackedModifier that takes a scenario and modifies multiple parameters at once.
• Implement MultiPeriodModifier. (ie, incorporate MultiPeriodModifier into PeriodicModifier)
• Address [Bug]: selected option for subpop_setup fails if modifiers apply to only a single subpop #490 if not already addressed by stricter validation (might require following up for details/cmds).
• Integrate ModifiersCollection into gempyor.seir/outcomes.
• Explore possibilities for Refactor Modifiers #570 (comment). Doable with some meta-programming, but loose the ability to validate inputs at configuration parse time.
• Ensure renaming from "reduce" to "apply modifiers"
• git rm the NPI subpackage.

Does this pull request make any user interface changes? If so please describe.

The user interface changes are...

Those are reflected in updates to the documentation in ...

What does your pull request address? Tag relevant issues.

This pull request addresses: #409.

[pearsonca]

Just some thoughts on the work in progress

[pearsonca]

This seems like a good start for a roll-our-own approach to distributions.

But: how much of an overhaul elsewhere would it be to just use https://www.pymc.io/projects/docs/en/stable/api/distributions.html (for example, there are other libraries that also manage this kind of thing)

[pearsonca]

It already seems like mostly what's happening is wrapping rng.SOMENAME - there is a way to have that as the default in the parent class (basically, use distribution field to know what function to call, have kwargs built from internal fields) and then override for the cases that really need to be custom (e.g. truncnorm)?

[jcblemai]

I could not really read the diff which is huge, and I don't follow much flepi but my 2-cent is that I would ditch the recursive autocall modifier thing, which makes anything like smart inference hard. I would load them all at once from config.

config breaking change I think are necessary:

• Every modifier is case of multi-timereduce so I would just keep this class to ease up the syntax. Probably something can be made to keep config for functioning
• I would probably ditched the stacked-modifier (not now perhaps) because it is confusing. But this is up to debate