TuringLang / MCMCTempering.jl

Implementations of parallel tempering algorithms to augment samplers with tempering capabilities
https://turinglang.org/MCMCTempering.jl/
MIT License
35 stars 5 forks source link

Is there any reason to return all of the PT chains, or should only the one where beta = 1 be returned in all cases? #20

Closed HarrisonWilde closed 1 year ago

HarrisonWilde commented 3 years ago

Title really, as a result of PT we end up with n chains for n inverse temperatures, one of these must be at an inverse temp of 1, i.e. the "correct" logdensity, do the other chains have any use? More a reminder to myself to read into if the others can be used for anything, but if anyone has ideas let me know here.

ParadaCarleton commented 3 years ago

Yes, the other chains can be used to calculate Bayes factors.

HarrisonWilde commented 1 year ago

This can be achieved using a state history callback, given these chains can have some utility, shall we plan to support this more directly? What do you think @torfjelde ?

torfjelde commented 1 year ago

IMO no because you can always access this by running step and calling transition_for_chain, etc.

The sample should return just what "standard" user needs, nothing more. Then if you want to do more complex stuff, then step and callbacks should be used:)

HarrisonWilde commented 1 year ago

Fair enough, I think as the package matures it may well be the case that we want to support a "friendly" way for people to diagnose potential mixing issues and so on at higher temperatures, in theory a naive way to tune a ladder would be to observe the mixing at the hottest level and if its poor then you probably havent tempered enough right? I would envision it being some boolean on the sampler that defaults to false but returns one chain per temp when true. Alternatively we could just export that callback you made as that might be a more Turing approach, this can be on the backburner though. I will close this for now and if it comes up we can rethink.

ParadaCarleton commented 1 year ago

IMO no because you can always access this by running step and calling transition_for_chain, etc.

You can access this by running step, but that's a substantially lower-level interface than most users will want to deal with. I don't see what the disadvantage of including this as a named tuple in the info field would be.