slow eight schools

[Matt Hoffman]

I've been looking into the eight schools model, and the issue seems to
be that the longer you run a chain for the greater your chances of
getting to a place where you wind up rejecting for a long time and
screwing up your ESS. This isn't because of bad adaptation—it happens
regardless of how long you adapt for. It's a potentially interesting
phenomenon, and one worth investigating further, insofar as it seems
to contradict the conventional wisdom that the only reason to run
multiple chains is so that you can do convergence monitoring.

More on this story as it develops.

[Andrew Gelman]

I thought that shouldn't happen with Nuts becasue then it would just take really short trajcetories?

[Marcus Brubaker]

Seems like this would arise either way, as short trajectories (even without rejection) would cause higher autocorrelation.

[Michael Betancourt]

Matt,

Are you saying that if run long enough the chain will make a transition of exceedingly low probability to an awkward region of the space that's horrible to sample from, and then by detailed balance it takes forever to get out of it?

[Matt Hoffman]

...maybe? Arguably I must be. It doesn't take forever, just a long time. I still need to examine the issue more closely.

[Matt Hoffman]

The problem is that it hits a region that's sufficiently unfriendly that it can't take even one step successfully. Hmc should also have this problem.

Arguably this means that the stepsize adaptation is failing to find a step size that's small enough for the whole parameter space. Which isn't surprising given that it takes so long to find these difficult spots.

[Andrew Gelman]

The 8 schools (actually, any hierarchical model) actually will take forever in Metropolis or Gibbs if you get close enough to the tau=0 point.  This is discussed in my JCGS paper with David Van Dyk. 

One way to solve the problem (in Gibbs/Metropolis, possibly also in HMC) is to do redundant parameterization.  I actually demonstrate that in the 8 schools case in Appendix C of BDA.  It is a mild annoyance, though.

I am expecting that one of our upcoming resarch projects (once stan is fully running) is to set up a new notation and coding for hierarchical models, in which case perhaps the redundant parameterization can be done invisibly.  Also there's the issue of saving finite-sample comparisons as quantities of intersest.  We can discuss further when we have time to think about this.

For now, I think we can accept that we have a problem that Bugs etc also have.

See you

A

[Bob Carpenter]

How easy is it to get out of the bad spot with
a small enough step size? We can randomize step
sizes around the one found by adaptation.

I think we will be able to do some higher-level
modeling. It should be easy to add to the Stan
language.

- Bob

>> > screwing up your ESS. This isn't because of bad adaptation�it happens

[Michael Betancourt]

It seems like this is the case that motivates not just a random jitter but also some large "jerks" towards smaller step sizes, a la Neal.

The graphical diagnoses should also pick this up.

>>> > screwing up your ESS. This isn't because of bad adaptation—it happens

[Bob Carpenter]

What I should've been asking is how small the
step size needs to be and then how many moves on
that small scale you need. If it's very small,
uniformly sampling on an interval won't get there.
But inserting known small steps every few iterations
could. And it would be very easy to implement.

- Bob

[Andrew Gelman]

My guess, based on my paper with Van Dyk et al., is that no step size will work if the sims happen to get close enough to 0. The only way I can see right now to solve it are: (a) parameter expansion, or (b) a prior that is zero at 0 and increases linearly from there in some small local region near 0. This should have the effect of kicking the sampler away from 0, which is what we want.

On the upside, we're no worse off than Bugs etc.

Another approach would be to have a possibility that is tied to diagnostics, where if there is a place that happens to be close to the boundary (e.g., tau near 0) where nothing's accepting, that we give the user the automatic option of slapping down a prior that kicks things away from 0. Given that these problems shoudl generally be happening at boundaries, this might actually be a reasonable option!

A

[Michael Betancourt]

Have we validated the rejections are occurring around tau = 0 and not some other pathological region of the parameter space?