You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The emcee.EnsembleSampler has the option to provide the parameter proposals as a dictionary with parameter_names as their keys. For sampling, this is useful, as especially the more complex models may have a lot of parameters that we do not always want to set (e.g. noext_contra_IItoIII_spread should be set only via IItoIII_spread most of the times).
For reproducibility purposes, it could be important to allow storing these parameter_names in the model (and its definition). Because unfortunately, the emcee.EnsembleSampler does not store the parameter_names in its backend.
I thought about an additional method, e.g. .set_named_params() that only allows setting parameters that are in a list of parameter_names provided to the constructor of the model. It could still allow setting them via a tuple, which would mean that - as long as the model is reliably reproducible - I can just pass in the samples from a previous run while being sure that the correct value is set at the right place in the model.
This method (and a corresponding .get_named_params()) could be implemented via a simple mixin and it would not introduce any breaking changes, fortunately.
The text was updated successfully, but these errors were encountered:
The
emcee.EnsembleSampler
has the option to provide the parameter proposals as a dictionary withparameter_names
as their keys. For sampling, this is useful, as especially the more complex models may have a lot of parameters that we do not always want to set (e.g.noext_contra_IItoIII_spread
should be set only viaIItoIII_spread
most of the times).For reproducibility purposes, it could be important to allow storing these
parameter_names
in the model (and its definition). Because unfortunately, theemcee.EnsembleSampler
does not store theparameter_names
in its backend.I thought about an additional method, e.g.
.set_named_params()
that only allows setting parameters that are in a list ofparameter_names
provided to the constructor of the model. It could still allow setting them via a tuple, which would mean that - as long as the model is reliably reproducible - I can just pass in the samples from a previous run while being sure that the correct value is set at the right place in the model.This method (and a corresponding
.get_named_params()
) could be implemented via a simple mixin and it would not introduce any breaking changes, fortunately.The text was updated successfully, but these errors were encountered: