sorry about the lack of feedback so far @SamuelSonoiki. @kylejcaron do you think this would complement arviz-devs/arviz-base#95 if ported over to arviz-base?

sorry about the lack of feedback so far @SamuelSonoiki. @kylejcaron do you think this would complement arviz-devs/arviz-base#95 if ported over to arviz-base?

yeah absolutely, this is a very similar pattern to the proposed SVIWrapper. The MCMC sampler in numpyro stores training data, while many other samplers don't. The approach @SamuelSonoiki and I both took is to have an adapter class so that the NumPyroConverter class requires less changes.

Why its necessary

Compared to MCMC...

SVI additionally requires

• The SVI instance (callable or purse function)
• The SVI result that stores fitted VI parameters
• The training data
• an rng_key
• Number of samples to generate (and then it needs to actually sample as opposed to MCMC)
• Missing thinning, chains, draws

while NestedSampler requires

• The Nested Sampler instance
• The training data
• an rng_key
• Number of samples to generate (and then it needs to actually sample as opposed to MCMC)
• Missing thinning, chains, draws

How we could approach this

Taking a second look at NumPyroConverter, the strategy I've taken so far is to try and change as little as possible from the original code so that the NumPyroConverter is "MCMC first"

What are your thoughts on using a Strategy Pattern with different Adapter classes for each sampler (MCMCAdapter, SVIAdapter, NestedSamplingAdapter, etc) to try and help generalize the NumPyroConverter? These would be inherited from an abstract base class that matches what NumPyroConverter expects. This would all be done under the hood so that people could still call az.from_numpyro(), az.from_numpyro_sampler(...), etc

I think if we pursued this I'd like to finish the az.from_numpyro_svi PR first and then pursue a refactor in case I run into unexpected issues. This nested sampler could be bundled in with the refactor, and this would help make future samplers easier to adapt. Seems like there's been alot of innovation with samplers and approximate bayesian inference lately

What are your thoughts on using a Strategy Pattern with different Adapter classes for each sampler (MCMCAdapter, SVIAdapter, NestedSamplingAdapter, etc) to try and help generalize the NumPyroConverter?

Sounds good, but also there is nothing inherent about NumPyroCoverter class itself that requires minimizing changes to it. If subclassing the converter itself helps also feel free to do that. Go with whichever seems more suited when tackling the refactor, no constraints on our side towards either alternative.

I think if we pursued this I'd like to finish the az.from_numpyro_svi PR first and then pursue a refactor in case I run into unexpected issues. This nested sampler could be bundled in with the refactor, and this would help make future samplers easier to adapt. Seems like there's been alot of innovation with samplers and approximate bayesian inference lately

Looks like a plan 🚀 , thanks for helping with this.

closing the PR for now, moving the discussion to arviz-devs/arviz-base#106 for nested sampling support