Annealed Importance Sampling

[treigerm]

I have an implementation of Annealed Importance Sampling (AIS) at https://github.com/treigerm/AnnealedIS.jl and @ParadaCarleton kindly suggested that I could merge it into an official Turing package and suggested this one. I was wondering what the best process is to merge my package into this one and if this is the best place.

Skimming through this repository it seems to me that the requirement for AIS and SMC are actually fairly different. AIS technically also has a set of particles but crucially there is no resampling step at observe statements. For a given Turing model AIS requires access to the following functions:

• The log joint density function of the parameters
• The log prior density function of the parameters
  If one wants to use AIS with an HMC transition kernel then we also requires access to the gradient of these functions. Additionally, ideally we want to be able to evaluate these function in parallel on a set of particles. You can see how I currently extract those functions from a Turing model here.

In summary, I have two questions:

• How should I add my implementation of AIS to this package? I.e. should I add it to the contrib folder?
• What is the "best practice" to extract the two functions mentioned above? Am I doing it correctly in my implementation?

[devmotion]

Is there a specific reason for why you would want to add it to AdvancedPS?

I had a quick look at your package and it seems much heavier dependency-wise than AdvancedPS. Eg., we don't depend on any AD packages and I don't think we can add dependencies on AdvancedHMC or AdvancedMH.

Basically, currently there are two levels of sampling algorithms. The basic standard implementations are Turing-independent and only implement the AbstractMCMC interface (eg AdvancedMH or EllipticalSliceSampling). These samplers require that you pass log-joints or loglikelihoods and priors (or whatever the algorithm needs) explictly. There's some discussion and plan for adding traits and defaults for such density models to AbstractMCMC, also to simplify swapping samplers. However, it might not be possible to make it fully automatic since different algorithms can have quite different requirements.

The other level us the integration of these samplers with Turing. Currently, this is done in Turing itself by extracting the required sampler-specific log density functions and parameters and foewarding them to the basic implementations. Maybe/hopefully this part can be simplified by AbstractPPL or better defaults in DynamicPPL/Turing/AbstractMCMC.

[treigerm]

There's no specific reason for me to want to add AIS to AdvancedPS, it was just suggested to me by someone else. The general implementation in AnnealedIS.jl follows the pattern that you described with the exception that the Turing integration is also directly implemented in AnnealedIS.jl.

So I get the impression that it is best to leave AnnealedIS.jl as a separate package but potentially add the Turing integration part directly to Turing? @ParadaCarleton was saying that there might be an AdvancedIS.jl for importance sampling at some point and when that package exists I might merge AIS into that package. Does that sound like a reasonable plan?

[devmotion]

Sounds reasonable to me 🙂 I don't think there's a completely compelling reason currently for moving it to AdvancedPS or another package. A separate package has also the advantage that you can add dependencies such as AdvancedHMC and AdvancedMH more freely and optimize it for your needs (it would be easy eg to depend on AdvancedPS as well but it doesn't seem helpful currently, I guess).

In my opinion, ideally the Turing/DynamicPPL integration would be done in the respective sampler packages but not in Turing itself. Currently, most integrations live in Turing to avoid that the standalone packages have to depend on Turing or Requires and have to deal with Turing internals. However, I still hope that at some point the lightweight interfaces such as AbstractPPL and AdvancedMCMC will allow us to implement these integrations in the individual packages without Turing dependencies or internals.

[treigerm]

Great, thanks! I will close this issue then.

[ParadaCarleton]

Is there a specific reason for why you would want to add it to AdvancedPS?

I had a quick look at your package and it seems much heavier dependency-wise than AdvancedPS. Eg., we don't depend on any AD packages and I don't think we can add dependencies on AdvancedHMC or AdvancedMH.

I did think that it made more sense in its own package, given it’s quite different from SMC, but @yebai mentioned he’d rather have it in AdvancedPS since he thought importance sampling algorithms wouldn’t be enough to warrant their own package.

Definitely strongly agree with the idea of hopefully having packages work with Turing without the necessity of glue code directly in Turing, I was talking about this on the Slack.