Adaptive Metropolis step method

[jsalvatier]

We should have an adaptive metropolis sampler.

@fonnesbeck Do you think this should be a release blocker?

[fonnesbeck]

Why don't I have a go at it? Its about time I contributed something to this release ;-)

I don't see why it should block an alpha, however.

[fonnesbeck]

By the way, are you confusing an adaptive M-H with an auto-tuning M-H? The Adaptive M-H (sensu Haario et al., 2001) uses the covariance matrix of an array-valued trace to update proposals, whereas the auto-tuing M-H just uses the acceptance rate of the trace to tune the proposal variance. We could have both, of course.

[jsalvatier]

Ah yes, I was. Adaptive M-H seems more important to me, since it solves the problem in https://github.com/pymc-devs/pymc/issues/210, whereas Auto-tuning M-H doesn't, does it?

Is there a combined version?

[jsalvatier]

Oh, and definitely take a stab at it.

If you can, see if you can separate out the auto-tuning logic so we can plug in different adaptation methods and reuse it elsewhere. The No U Turn sampler also requires auto-tuning for e, though it uses "dual averaging" (see the paper http://arxiv.org/abs/1111.4246).

[fonnesbeck]

Sounds good. When its finished, we might rename the current Metropolis as something like HamiltonianMetropolis, and use Metropolis for the text-book version, as well as AdaptiveMetropolis for the Haario sampler.

[jsalvatier]

Wait, I think the metropolis sampler is pretty text book unless I'm missing something. Do you mean because it's multivariate? Or because it uses Quadpotential? Quadpotential is basically just a way to set the proposal distribution, which I used because we already had it.

On Tue, Apr 30, 2013 at 12:42 PM, Chris Fonnesbeck <notifications@github.com

wrote:

Sounds good. When its finished, we might rename the current Metropolis as something like HamiltonianMetropolis, and use Metropolis for the text-book version, as well as AdaptiveMetropolis for the Haario sampler.

— Reply to this email directly or view it on GitHubhttps://github.com/pymc-devs/pymc/issues/212#issuecomment-17249713 .

[fonnesbeck]

I had assumed because of quadpotential, yes .. I thought it was using velocity & energy to determine the proposals. By "textbook", I was just thinking in terms of generating proposals from an arbitrary distribution, the scale parameter of which can be tuned. So, I was going to provide normal, cauchy, laplace proposals. I suppose I could stick with the quadpotential, since I think 90% of folks use a normal proposal (of course as soon as we do this, someone will ask for arbitrary proposals).

[jsalvatier]

Yeah, good idea. Right now it's just quadpotential, but it would be easy to add that as a parameter that can be passed in to MH.

On Tue, Apr 30, 2013 at 1:34 PM, Chris Fonnesbeck notifications@github.comwrote:

I had assumed because of quadpotential, yes .. I thought it was using velocity & energy to determine the proposals. By "textbook", I was just thinking in terms of generating proposals from an arbitrary distribution, the scale parameter of which can be tuned. So, I was going to provide normal, cauchy, laplace proposals. I suppose I could stick with the quadpotential, since I think 90% of folks use a normal proposal (of course as soon as we do this, someone will ask for arbitrary proposals).

— Reply to this email directly or view it on GitHubhttps://github.com/pymc-devs/pymc/issues/212#issuecomment-17252367 .

[fonnesbeck]

I've pushed a Metropolis-Hastings implementation with simple tuning to a branch called metropolis (644058d33b8a3fb92f73ad7982cfb0bcfbdc0d51). I also generalized it to be able to use a few other proposal distributions. See what you think.