Add a Metropolis-within-Gibbs sampler

[rlouf]

Following #16 we should implement a Metropolis-within-Gibbs sampler similar to PyMC's (algorithms listed in this file) that uses NUTS to update the RVs with continuous variables and Gibbs samplers / others to update the RVs with discrete support.

This way we can start attracting users who will interact with a generic build_sampler (name tbd) function, and we will have a first performance benchmark. It will be a big step towards #3.

[rlouf]

The PyMC sampler is a Metropolis-within-Gibbs sampler, we separate the variables in different groups and sample from the conditional logprob of all these groups subsequently:

• RVs with continuous support: NUTS sampler (Add the NUTS sampler constructor #35)
• Bernoulli RVs: an update step optimized for Bernoulli RVs
• Categorical RV:an update step optimized for Categorical RVs.
• Other RVs with discrete support: RW Metropolis

[rlouf]

Note that samplers other than NUTS won't be necessary if marginalisation of discrete RVs is implemented in aesara-devs/aeppl#21 is

[brandonwillard]

Note that samplers other than NUTS won't be necessary if marginalisation of discrete RVs is implemented in aesara-devs/aeppl#21 is

Unless I'm interpreting this issue and/or its comments incorrectly, we shouldn't need an explicit sampler for this functionality.

Instead, we should have a generic process that uses an internal sampling-step database (i.e. #3) to find sampling steps for the relevant terms in a model graph, then applies NUTS—or any other generalizable sampling approach—to the remaining terms. The end result is likely to be a *-within-Gibbs approach to sampling the entire model, but it could also be an entirely Gibbs/NUTS-based approach as well.

How we arrive at a given full-model sampler ultimately will depend on our database, sampler-selecting heuristics, and user-configurable settings.

[rlouf]

Unless I'm interpreting this issue and/or its comments incorrectly, we shouldn't need an explicit sampler for this functionality.

The goal of this issue was to identify a set of sampling steps that is sufficient to be able to sample any kind of model and make the library usable by anyone who is already using PyMC. NUTS + marginalization of random variables with discrete support is one way to get to this point.

The general framework is described in #3, and what is described here is by no means exhaustive. I expect AeMCMC to quickly generate samplers that are way more efficient than PyMC's as they're tailored to the model provided by the user.

[brandonwillard]

I updated the title to reflect the specificity of having a generalized Metropolis-within-Gibbs sampler.

A general purpose sampler would definitely work as described in #26 (comment) and—more generally—#3. It's the next thing on our list of most important things to do, especially since it's the definition of our user-facing entry point for this library.

[brandonwillard]

The goal of this issue was to identify a set of sampling steps that is sufficient to be able to sample any kind of model and make the library usable by anyone who is already using PyMC.

To be clear, such a set would necessarily consist of a subset of the samplers we have implemented in this library, and the identification/production of these subsets is the focus of #3.

A general Metropolis-within-Gibbs sampler would not actually help with #3, because it wouldn't get us any closer to automatically assigning our existing samplers and/or a framework that would do so.

[rlouf]

I'm closing this because since #3 and after #47 we will effectively have that, so this issue is redundant. We can open separate issues for the sampling steps mentioned above.