Callbacks can be incredibly useful, e.g. TuringCallbacks.jl with TensorBoardLogging.jl integration.
However, there are many "standard" callbacks that we arguably should provide some default implementation (i.e. that have "zero" dependencies) of:
The question is then: should these go in AbstractMCMC.jl itself, or should we put them in a separate package?
And if we're putting them in a separate package (which I also think is the best approach here), then do we put them in a package called AbstractMCMCCallbacks.jl or in the existing TuringCallbacks.jl?
Thoughts? @devmotion @yebai @sunxd3 @mhauru @penelopeysm
Callbacks can be incredibly useful, e.g. TuringCallbacks.jl with TensorBoardLogging.jl integration.
However, there are many "standard" callbacks that we arguably should provide some default implementation (i.e. that have "zero" dependencies) of:
StateHistoryCallback: simply extracts the states from asamplecall. This is useful if one wants to inspect sampler parameters, etc. that aren't necessarily part of the transitions. Ref:sampleequivalent but including states #84MultipleCallback: a wrapper around multiple callbacks to make it easier to pass many of them. Ref: Allow multiple callbacks #80The question is then: should these go in AbstractMCMC.jl itself, or should we put them in a separate package?
And if we're putting them in a separate package (which I also think is the best approach here), then do we put them in a package called AbstractMCMCCallbacks.jl or in the existing TuringCallbacks.jl?
Thoughts? @devmotion @yebai @sunxd3 @mhauru @penelopeysm