External samplers docs #403
Conversation
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
…ents_abstractmcmc.md Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
…ents_abstractmcmc.md Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
…g/TuringTutorials into external_samplers_docs
| So far we have used to Turing's support for external samplers to go beyond the capabilities of the wrappers. | ||
| Now we want to use this support to employ a sampler not supported within Turing's ecosystem yet. | ||
| We will use the recently developped Micro-Cannoncial Hamiltonian Monte Carlo (MCHMC) sampler to showcase this. | ||
| MCHMC[^3,^4] ((MCHMC's GitHub)[https://github.com/JaimeRZP/MicroCanonicalHMC.jl]) is HMC sampler that conserves energy along the exploration of the phase space. |
There was a problem hiding this comment.
is HMC sampler that conserves energy along the exploration of the phase space.
What does this actually mean? For example, HMC preserves energy along the trajectory; is this the same or not?
There was a problem hiding this comment.
Not extactly. hopefully this plot adds clarity.
I have rephrased the sentences.
| As previously stated, in order to use external sampling libraries within `Turing` they must follow the `AbstractMCMC` API. | ||
| In this section we will briefly dwell in what this entails. | ||
| First and foremost, the inference method must be of the type `typeof(spl)<:AbstractMCMC.AbstractSampler`. | ||
| Second, the stepping function of the MCMC algorithm must be made into instances of `AbstractMCMC.step` and follow the structure below: |
There was a problem hiding this comment.
Usage of "instance" here is somewhat confusing; "instance" in this context usually refers to the instance of some type.
| The last requirement is that the transition must be structure with a field named `θ` which constains the values of the parameters of the model for said transition. | ||
| This allows `Turing` to seemlessly extract the parameter values at each step of the chain when bundling the chains. | ||
|
|
||
| For a practical example of how to adapt a sampling library to the `AbstractMCMC` interface the readers can consult the following (code)[https://github.com/JaimeRZP/MicroCanonicalHMC.jl/blob/master/src/abstractmcmc.jl] within `MicroCanonicalHMC`. |
There was a problem hiding this comment.
Is this really the best example of an implementation of the interface?
Looking at the code, most of the complexity seems to be hidden in your Step type, and so it the AbstractMCMC.step function seems almost "useless", no?
Of course some implementations of the interface will indeed be like this, but it doesn't seem like the greatest example of how these things are usually done?
For example, something like https://github.com/TuringLang/AdvancedMH.jl/blob/458a602ac32a8514a117d4c671396a9ba8acbdab/src/mh-core.jl#L73-L115 is IMO a slightly better example.
https://github.com/TuringLang/AdvancedHMC.jl/blob/762e55f894d142495a41a6eba0eed9201da0a600/src/abstractmcmc.jl#L102-L170 might be even better because it demonstrates the difference between transition and state nicely.
But IMO, we should just have a simple example of how to implement something like a MH algorithm in the docs of AbstractMCMC; that would be ideal 😬
There was a problem hiding this comment.
I turned this into a list of examples.
| The last requirement is that the transition must be structure with a field named `θ` which constains the values of the parameters of the model for said transition. | ||
| This allows `Turing` to seemlessly extract the parameter values at each step of the chain when bundling the chains. |
There was a problem hiding this comment.
This part is still something I'm not too keen on. Basically, the current way of converting a transition to something that bundle_samples can handle is really not great and I don't expect anyone outside of Turing.jl to implement this 😕
There was a problem hiding this comment.
I think for the time being it is quite an important consideration for devs who want to make the connection as seemless as possible.
We can change it as we change the code.
There was a problem hiding this comment.
For certain, but it's an aspect of the implementation that is bound to change very rapidly from the current state, to the point where I really don't want to have downstream packages rely on it (the result is that we might end up making non-breaking release, which subsequently ends up breaking downstream packages because we encouraged usage of internal and volatile code 😕 )
So I'd rather just say "Right now, it's still non-trivial to make it so the resulting samples are also bundled nicely into a MCMCChains.Chains, but this is being worked on (see this issue)." and link to some issue where we keep track of this:)
Co-authored-by: Tor Erlend Fjelde <[email protected]>
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
yebai
force-pushed
the
external_samplers_docs
branch
from
2d36ff1
to
6ec06d3
Compare
This reverts commit 32284d5.
…g/TuringTutorials into external_samplers_docs
|
I'Ill try to have a look at this during weekend, if need be:) |
|
For some reason it still is using [email protected] instead of the [email protected] |
|
Thanks @JaimeRZP! |
Docs for Turing's #2008.