rhayes777
Add Starting Point result passing
Prior passing passes a result as a GaussianPrior, where the mean and sigma are set via config files.
We should add a new type of model passing result, something like result.start which passes the result as a StartingPoint object described in issue https://github.com/rhayes777/PyAutoFit/issues/200
That is what I thought at first!
The difference is you could imagine having a UniformPrior with lower_limit=1.0, upper_limit=10.0, and wanting all points to spawn around the value 2.0.
class InitializerBall(Initializer):
def __init__(self, lower_limit, upper_limit):
"""
The Initializer creates the initial set of samples in non-linear parameter space that can be passed into a
`NonLinearSearch` to define where to begin sampling.
Although most non-linear searches have in-built functionality to do this, some do not cope well with parameter
resamples that are raised as FitException's. Thus, PyAutoFit uses its own initializer to bypass these problems.
The InitializerBall class generates the samples in a small compact volume or 'ball' in parameter space, which is
the recommended initialization strategy for the MCMC `NonLinearSearch` Emcee.
Parameters
----------
lower_limit : float
The lower limit of the uniform distribution unit values are drawn from when initializing walkers in a small
compact ball.
upper_limit : float
The upper limit of the uniform distribution unit values are drawn from when initializing walkers in a small
compact ball.
"""
super().__init__(lower_limit=lower_limit, upper_limit=upper_limit)
You could do this by adjusting the lower_limit and upper_limit values of InitializerBall method, however you could not do this for every individual parameter whilst maintaining their original priors.
So, we want the StartPoint to spawn all points at the input location (with a small amount of scatter) but to retain the original prior that comes from the config files or user.
I wonder if it makes sense to put it in the Prior class? Feels like polluting the code for a single optimiser but it could make sense
It isn't a single optimizer, it'll be used by all MCMC methods, the Particle Swarm and I would guess most Scipy codes. Its only nested sampling this wouldn't be applicable for.
I think that whether or not a parameter has a StartPoint it'll always have a Prior regardless. Maybe it belongs in the initializer.py module?
The StartPoint is never used after the search has begun.
It seems sensible then to put it in a Prior. If it's not present the Prior can simply default to the median value.
Indeed, we should also have a bool in a Search that by default disables start points but if set to True enables them (so I can manually set it to true in every MCMC, Optimizer, etc.). This will ensure an exception is raised whenever a Nested sampler has a StartPoint passed to it.