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

Usefulness of reflective/periodic dimensions #410

Open
segasai opened this issue Nov 10, 2022 · 2 comments
Open

Usefulness of reflective/periodic dimensions #410

segasai opened this issue Nov 10, 2022 · 2 comments
Labels
question questions about stuff

Comments

@segasai
Copy link
Collaborator

segasai commented Nov 10, 2022

In all the tests that I have done I don't think I have seen any benefits from reflective or periodic conditions which makes me wonder whether they are useful at all or not.

Here is the example where in theory periodic conditions should make sense, but here for rwalk sampler the number of function calls is actually smaller when not using periodic option and for the rslice it's exactly the same. Only for unif sampler the usage of periodic leads to 20% smaller number of ncalls

import numpy as np
import dynesty

nlive = 100
printing = True
ndim = 2


def loglike(x):
    return -0.5 * x[1]**2 - 10 * np.cos(np.pi * x[0])


def prior_transform(x):
    return (2 * x - 1)


def doit():
    dynamic = True
    sampler = 'rwalk'
    # hard test of dynamic sampler with high dlogz_init and small number
    # of live points
    per = [0]
    per = None
    rstate = np.random.default_rng(1)
    if dynamic:
        dns = dynesty.DynamicNestedSampler(loglike,
                                           prior_transform,
                                           ndim,
                                           nlive=nlive,
                                           sample=sampler,
                                           periodic=per,
                                           rstate=rstate)
    else:
        dns = dynesty.NestedSampler(loglike,
                                    prior_transform,
                                    ndim,
                                    nlive=nlive,
                                    sample=sampler,
                                    periodic=per,
                                    rstate=rstate)
    dns.run_nested(print_progress=printing)
    return dns.results


if __name__ == '__main__':
    res = doit()
  • I think part of the problem lies in the clustering. I.e. periodic= makes sense if the code would recognise the posterior mode that is wrapping around the boundary as a single mode, but that's not what's happening. The clustering/ellipsoid splitting is not aware of that.
    But even without addressing the issue of clustering, it's not clear if
  • the benefit of periodic conditions is actually worth anything measurable (at least for rwalk/slice)
  • it's implemented correctly for non-unif

Also it is clear that we need an example that should serve as test-case for periodic doing anything useful (like the one given here; but maybe there is a better one).

Thoughts ?

@segasai segasai added the question questions about stuff label Nov 10, 2022
@ColmTalbot
Copy link
Contributor

The number of likelihood evaluations is essentially a deterministic function of the MCMC length + number of live points + likelihood for rwalk, so I would expect the number of calls per run to not be strongly affected.

What is strongly affected is the quality of the convergence. Did you look at the posteriors in this case? In my experience, the periodic boundaries (for periodic parameters) significantly decrease the required MCMC length to get unbiased posteriors.

@segasai
Copy link
Collaborator Author

segasai commented Nov 14, 2022

That is a fair point.

The question is what kind of statistic we should look into here to have an objective characterisation of whether these parameters improve things.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question questions about stuff
Projects
None yet
Development

No branches or pull requests

2 participants