After lookin through the dynesty python package, I think some design changes should be made here for more easily extending the behavior of the sampler.
Currently I am using the multi vs single method terminology incorrectly. These describe the bounds of the active sampling space, and there are more methods than ellipsoidal.
Also, right now I have implicitly chosen a proposal type which is just direct sampling, although adding slice, rslice, random walk, etc. are orthogonal to the choice of bounds, Hoch I’ve put all under the method keyword arg.
So the design needs reworked to allow easier composability of bounds and proposal types. In fact, all of the EllipticalSliceSampling.jl could be implemented within this abstraction.
After lookin through the dynesty python package, I think some design changes should be made here for more easily extending the behavior of the sampler.
Currently I am using the multi vs single method terminology incorrectly. These describe the bounds of the active sampling space, and there are more methods than ellipsoidal.
Also, right now I have implicitly chosen a proposal type which is just direct sampling, although adding slice, rslice, random walk, etc. are orthogonal to the choice of bounds, Hoch I’ve put all under the method keyword arg.
So the design needs reworked to allow easier composability of bounds and proposal types. In fact, all of the EllipticalSliceSampling.jl could be implemented within this abstraction.