Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Alternative to Raftery-Lewis diagnostic #26

Open
rolyp opened this issue May 13, 2021 · 1 comment
Open

Alternative to Raftery-Lewis diagnostic #26

rolyp opened this issue May 13, 2021 · 1 comment

Comments

@rolyp
Copy link
Collaborator

rolyp commented May 13, 2021

The Raftery-Lewis diagnostic for MCMC convergence isn’t well supported in Python. Importing the raftery.diag function from the R library coda into Python somewhat defeats the purpose of a Python port, so we could consider other (more widely used) diagnostics.

@rolyp rolyp added this to To do in Python port via automation May 13, 2021
@rolyp
Copy link
Collaborator Author

rolyp commented May 13, 2021

Comments from Greg Mingas:

I believe PyMC3 has the Gelman-Rubin diagnostic which detects convergence based on how similar the results from multiple MCMC chains are. Not sure if it is implemented within PyMC3 in the latest version, I think they have started using arviz (external library with close integration): https://arviz-devs.github.io/arviz/api/generated/arviz.rhat.html

Gelman Rubin I think is a widely used diagnostic in MCMC literature, I do not remember encountering Raftery-Lewis a lot.

Comments from Oscar Giles:

I think Raftery-Lewis is getting at something a bit different from Gelmen Rubin so other statistics might not cover the use case. Rather than “have i converged?” it asks “how many iterations do i think i would need to converge?”.
Asking that question makes sense when running your models is very costly because:

  • each iteration takes a long time
  • your algorithm is producing highly auto-correlated chains so you need more samples to get good precision
  • you don’t have much memory so you might want to use thinning and you need to figure out what you could get away with

The other approach would be to run a lot of iterations and then estimate precision after the fact (with something like https://mc-stan.org/posterior/reference/mcse_quantile.html). Then rerun with more iterations if you didn’t do well enough.
I suspect that Raftery-Lewis is not used much now because the second approach is now often feasible - computers faster/plenty memory/more efficient algorithms (like NUTS/HMC in Pymc3).

@rolyp rolyp moved this from To do to Proposed in Python port Sep 2, 2021
@rolyp rolyp moved this from Proposed to To do in Python port Sep 13, 2021
@rolyp rolyp removed the proposed label Sep 13, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Python port
Proposed
Development

No branches or pull requests

1 participant