Closed jasonmhite closed 6 years ago
Hi Jason,
We happily accept pull requests for new PyMC 2.3 functionality despite not having a roadmap for further development of the package. If you happen to refactor AdaptiveMetropolis
in a way that makes it more general or extendable, all the better. It sounds like what you propose is a logical subclass of AdatpiveMetropolis
, but don't feel constrained by this if that presents hurdles that make subclassing difficult or artificial.
This would probably be useful in PyMC3 as well. Although PyMC3 focuses on gradient-based methods, we still have to fall back on Metropolis-type algorithms for models that include discrete latent variables that cannot be integrated out.
I was leaning towards refactoring AdaptiveMetropolis
, as you say DRAM makes sense as a subclass but the problem is that most of the changes are in the step
method. DRAM needs to basically do everything that Adaptive Metropolis is already doing in step
, but then do a few more things. So if I subclass AdaptiveMetropolis
I have to duplicate all that code in step
in my class.
I will get to work on tidying it up. I should have something within a couple weeks.
If this is something you are still working on, please submit a PR when it is ready.
I'm working on implementing the DRAM sampler due to Haario et al. (see also this page).
The AM is for Adaptive Metropolis, which is obviously already there. To implement the full DRAM algorithm I just need to add a delayed rejection phase. I wanted to ask for opinions on how I should do this in a way that is most likely to be accepted in a PR. To me it seems most natural to implement this as part of the existing
AdaptiveMetropolis
algorithm, since the two algorithms are almost always used together and share the same provenance via Heikki Haario. This however will require a bit of refactoring of the currentAdaptiveMetropolis
class because the current implementation is only really designed to propose a single candidate. Alternatively I could implement it as a subclass ofAdaptiveMetropolis
, but I will end up duplicating a ton of code because I have to reimplement thestep
method even though it'll still be doing everything thatAdaptiveMetropolis.step
is doing.I already have a prototype implemented that I can work into either approach (currently it's modifying
AdaptiveMetropolis
). In most of the problems I've looked at the delayed rejection portion of the algorithm is much more important than the adaptive covariance when it comes to improving the acceptance ratio. In the toy problem I have been testing with I got a factor of two improvement using DR+AM versus just using AM, so it's a clear improvement.Also, in principle delayed rejection can proceed for as many rounds as you want (see the original paper). However in practice most people only use a single round and that's what I implemented. Laine's MATLAB implementation that I linked (the de facto standard implementation) only uses a single round.
PS: I personally need this implemented in PyMC 2, but I'm open to working on an implementation in PyMC 3 later if desired. I'll implement/update unit tests too of course. I should also be able to provide some validation studies too.