Dense Adaptation Fragile

[alashworth]

Issue by betanalpha Sunday Apr 10, 2016 at 21:32 GMT Originally opened as https://github.com/stan-dev/stan/issues/1853

---

Summary:

The covariance estimation currently used to construct a dense mass matrix is yielding sufficiently poor results that the resulting chains go crazy.

Description:

It looks like the regularization in covar_adaptation.hpp is insufficient. The initial estimates of the covariance are so noisy that they cause the subsequent adaptation windows to fail miserably. Adding stronger regularization helps, but it's not clear if this is a sufficiently robust solution.

Reproducible Steps:

Try to fit the simple model

parameters {
  real mu[10];
}
model {
  mu ~ normal(0, 1);
}

with the CmdStan configuration

./gauss sample num_samples=10000 algorithm=hmc metric=dense_e

Current Output:

Completely biased results. The diagnostics do indicate that the fit results should not be trusted.

Expected Output:

Accurate results. We should be able to fit an IID Gaussian.

Current Version:

develop

[alashworth]

Comment by farr Wednesday Dec 05, 2018 at 16:38 GMT

---

I can confirm that this behavior persists into the present day. Just did a ~10 dimensional sampling run using PyStan 2.18.0.0 and found crazy jumps in log-posterior (i.e. changes in log posterior of -10^5) appearing in the sampling chains, which can only be down to the mass matrix going singular (so the drop in log-posterior can be compensated by an equally large increase in the kinetic term). Switching from control = {'metric': 'dense_e'} to the default (which I assume is diag_e) solved the problem (and, as you would expect, took sampling times down from many hours to a few minutes).

Any thoughts on the source of the issue? Could the variance accumulator have some subtle bug that leads to growing variances?

[alashworth]

Comment by bgoodri Wednesday Dec 05, 2018 at 16:55 GMT

---

You need to get the develop version of Stan from GitHub if you want to do dense HMC. The implementation of it for 2.18 and earlier was just wrong.

https://github.com/stan-dev/stan/issues/2671

On Wed, Dec 5, 2018 at 11:38 AM Will Meierjurgen Farr < notifications@github.com> wrote:

I can confirm that this behavior persists into the present day. Just did a ~10 dimensional sampling run using PyStan 2.18.0.0 and found crazy jumps in log-posterior (i.e. changes in log posterior of -10^5) appearing in the sampling chains, which can only be down to the mass matrix going singular (so the drop in log-posterior can be compensated by an equally large increase in the kinetic term). Switching from control = {'metric': 'dense_e'} to the default (which I assume is diag_e) solved the problem (and, as you would expect, took sampling times down from many hours to a few minutes).

Any thoughts on the source of the issue? Could the variance accumulator have some subtle bug that leads to growing variances?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/stan-dev/stan/issues/1853#issuecomment-444553065, or mute the thread https://github.com/notifications/unsubscribe-auth/ADOrqkUoKnihRsKP5K3hC0FEh4cbZPiBks5u1_aegaJpZM4ID8lU .

[alashworth]

Comment by farr Thursday Dec 06, 2018 at 02:29 GMT

---

Oh---great. Thanks!

Will

On Wed, Dec 5, 2018 at 11:55 AM bgoodri notifications@github.com wrote:

You need to get the develop version of Stan from GitHub if you want to do dense HMC. The implementation of it for 2.18 and earlier was just wrong.

https://github.com/stan-dev/stan/issues/2671

On Wed, Dec 5, 2018 at 11:38 AM Will Meierjurgen Farr < notifications@github.com> wrote:

I can confirm that this behavior persists into the present day. Just did a ~10 dimensional sampling run using PyStan 2.18.0.0 and found crazy jumps in log-posterior (i.e. changes in log posterior of -10^5) appearing in the sampling chains, which can only be down to the mass matrix going singular (so the drop in log-posterior can be compensated by an equally large increase in the kinetic term). Switching from control = {'metric': 'dense_e'} to the default (which I assume is diag_e) solved the problem (and, as you would expect, took sampling times down from many hours to a few minutes).

Any thoughts on the source of the issue? Could the variance accumulator have some subtle bug that leads to growing variances?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/stan-dev/stan/issues/1853#issuecomment-444553065, or mute the thread < https://github.com/notifications/unsubscribe-auth/ADOrqkUoKnihRsKP5K3hC0FEh4cbZPiBks5u1_aegaJpZM4ID8lU

.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/stan-dev/stan/issues/1853#issuecomment-444559264, or mute the thread https://github.com/notifications/unsubscribe-auth/AAFfwEeLAMmVDWPfH_JE4Wxt7SyQDRC4ks5u1_p7gaJpZM4ID8lU .