-
-
Notifications
You must be signed in to change notification settings - Fork 2k
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
[WIP] Implement elliptical slice sampler #1755
Conversation
This all looks positive. I would need to dig into the papers to give this a
proper review.
The cholesky decomposition and other features sound worthy of a separate PR.
I would love some insight into why you use this stuff over Metropolis
Hastings.
…On 5 Feb 2017 4:58 AM, "Jonathan Friedman" ***@***.***> wrote:
Here's the beginnings of an elliptical slice sampler implementation (#1643
<#1643>), and a quick
demonstration in demo-ess.ipynb that it works on the very simple problem
of Gaussian prior/likelihood (the "Gaussian regression" example in the original
paper <http://www.jmlr.org/proceedings/papers/v9/murray10a/murray10a.pdf>).
I was hoping that some more experienced people could provide advice.
Currently you pass the prior covariance to the sampler and it samples from
a zero mean multivariate normal directly, but it might be nicer/cleaner to
pass in the Cholesky decomposition and sample by multiplying with a
standard mv normal. Maybe we should support either option. I'd also still
like to work on supporting priors with nonzero means
<http://www.michaelchughes.com/blog/2012/08/elliptical-slice-sampling-for-priors-with-non-zero-mean/>
.
------------------------------
You can view, comment on, or merge this pull request online at:
#1755
Commit Summary
- minimal elliptical slice sampler implementation
- rearrange a few lines, add caveat
File Changes
- *A* docs/source/notebooks/demo-ess.ipynb
<https://github.com/pymc-devs/pymc3/pull/1755/files#diff-0> (259)
- *M* pymc3/step_methods/__init__.py
<https://github.com/pymc-devs/pymc3/pull/1755/files#diff-1> (2)
- *A* pymc3/step_methods/elliptical_slice.py
<https://github.com/pymc-devs/pymc3/pull/1755/files#diff-2> (67)
Patch Links:
- https://github.com/pymc-devs/pymc3/pull/1755.patch
- https://github.com/pymc-devs/pymc3/pull/1755.diff
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#1755>, or mute the thread
<https://github.com/notifications/unsubscribe-auth/AA8DiMT39mRr2Dxhqdh9iFgztDA2cU_qks5rZVbqgaJpZM4L3Y-f>
.
|
model : PyMC Model | ||
Optional model for sampling step. Defaults to None (taken from context). | ||
""" | ||
default_blocked = False |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As this operates on the full join, you need to set this to True
. Otherwise, a separate ESS will be used for each RV.
Thanks for the feedback @springcoil and @twiecki. As I understand it, the selling point of elliptical slice sampling is that it is about as fast as vanilla slice sampling, mixes well no matter the prior covariance, and requires no parameter tuning. The downside is that it requires a multivariate normal prior. |
This also allows for the sampling of multivariate (or vector-valued) nodes, does it not? Our slice sampler only works well with scalar variables. |
Yep, but only if they have normal priors. |
.. [1] I. Murray, R. P. Adams, and D. J. C. MacKay. "Elliptical Slice | ||
Sampling", The Proceedings of the 13th International Conference on | ||
Artificial Intelligence and Statistics (AISTATS), JMLR W&CP | ||
9:541–548, 2010. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
that's a sneaky em-dash -- can't be included in python2 source code!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wow, good catch!
dc4bc91
to
db8fb5a
Compare
@jonathanhfriedman Can we make the GP example a bit more salient (more variability in y-coordinates)>? |
@twiecki Definitely. I'm also working on having it sample the noise/length scale/vertical function scale to make it a little less contrived and more comparable to the existing GP regression example. |
@jonathanhfriedman Hm, would we not expect the true length-scale to be within the posterior region? |
For that example, there's not really a true length scale since the data isn't actually generated from a GP. I guess that doesn't make it particularly instructive, though... Anyway, I redid the example so that it now just focuses on sampling from the posterior given a prior and likelihood and doesn't cover fitting covariance kernel parameters. Maybe best to keep things simple and focus on what ESS does well. |
@jonathanhfriedman OK, sounds good. And can you confirm that NUTS produces the same results on these models? |
@twiecki NUTS and ESS produce the same results with fewer (10) data points, but with 30 points, all the other samplers seem to either not get started at all or fail to sample from the whole distribution. |
@jonathanhfriedman Pretty good advertisement for ESS then :). I resolved a conflict but it seems you still need to rebase. |
b9df4db
to
541ff89
Compare
@twiecki I think that should fix all the conflicts. Shall I squash the commits or would you prefer to squash them when you merge? |
@jonathanhfriedman Great, contribution, thanks! |
Here's the beginnings of an elliptical slice sampler implementation (#1643), and a quick demonstration in
demo-ess.ipynb
that it works on the very simple problem of Gaussian prior/likelihood (the "Gaussian regression" example in the original paper). I was hoping that some more experienced people could provide advice.Currently you pass the prior covariance to the sampler and it samples from a zero mean multivariate normal directly, but it might be nicer/cleaner to pass in the Cholesky decomposition and sample by multiplying with a standard mv normal. Maybe we should support either option. I'd also still like to work on supporting priors with nonzero means.