[AstroPy] [ANN] Nestle: Nested sampling
Anne Archibald
archibald at astron.nl
Fri Oct 9 12:26:25 EDT 2015
Hi Scott,
In fact I had parallel tempering working for a while, as a help to the
minimization. In one sense it's relatively cheap: since the
different-temperature chains are run in parallel, you can throw more
walkers and hence more cores at the problem. But it suffers from something
of the same problem as nested sampling: if you want to explore the whole
space, you need much higher temperatures than the base one, and the
temperature spacing can't be more than about 2^(1/n_parameters). So you
need a bazillion chains. That said, I don't know how much actual
probability the far-away parts of the space contribute to the integral, or
how to evaluate how well parallel tempering is working. For context,
though, the problem as implemented has two identical optima: a cos i and -a
cos i are equivalent until I put in the full astrometry. But parallel
tempering didn't find the other optimum.
For the problem of testing GR versus not-GR specifically, we might be able
to get away with using priors based on the Newtonian fit - it's the same
data, so that's maybe not quite kosher, but it does very dramatically
reduce the prior volume, maybe to a manageable level.
How is the PINT BTX model? I have a test problem - 30000 data points, two
sinusoids - that should produce similar prior/posterior constraints, but it
doesn't have that many parameters. If PINT BTX could be used, that would
give me a slightly more realistic problem. I could use the
two-noninteracting-Keplerian model I have but it's actually even slower to
evaluate than the integrator (don't ask). Anyway, the way to answer these
questions about what parallel tempering and nested sampling can do is to
run some tests with a much cheaper log-likelihood.
Anne
On Fri, Oct 9, 2015 at 5:59 PM Scott Ransom <sransom at nrao.edu> wrote:
> Hey Anne,
>
> Can you use parallel tempering MCMC to estimate the evidence for
> hypothesis testing? Or will that work terribly badly for us given the
> dynamic range between prior to posterior?
>
> e.g. http://dan.iel.fm/emcee/current/user/pt/
>
> Scott
>
> On 10/08/2015 05:05 PM, Anne Archibald wrote:
> > Hi Kyle,
> >
> > I am very interested in nestle as an alternative MCMC method for a
> > project I'm working on (testing general relativity with pulsar timing
> > observations of a triple system; see
> > http://adsabs.harvard.edu/abs/2014Natur.505..520R for more). I was
> > considering multinest but the ability to get "under the hood" is really
> > valuable. I have several concerns with using the code; maybe you have
> > the experience to point me in the right direction.
> >
> > The first concern is that my likelihood function is really slow
> > (seconds). I have access to many cores, but each evaluation can only use
> > one. So I'd like to enlist some parallelism in the MCMC algorithm. As
> > written, nestle is purely sequential, but I can see several places
> > parallelism is available. The first and easiest is when picking a new
> > point to replace the worst: if this takes many tries, you could
> > speculatively evaluate the function at many new candidate points and
> > take the first acceptable one. Multinest is able to do this, and I can
> > see how one might add it to the code here. The second possibility is
> > suggested by your "update_interval" parameter. Until the family of
> > ellipsoids is updated, all new points are being generated from the same
> > distribution, so the evaluation of their likelihoods can be carried out
> > in parallel. This guarantees at least a factor update_interval worth of
> > parallelism, which might be worth it even for expensive likelihood
> > evaluations. Implementation would maintain a list of N (~ number of
> > cores) Futures representing evaluations drawn from the current set of
> > ellipsoids; every time the code needs a new point it waits for the first
> > Future to finish and gets the coordinates and log-likelihood from that,
> > then creates another Future for later. When the ellipsoids need to be
> > changed, all unused Futures can be cancelled. The result should be
> > statistically identical to the current algorithm, though it sometimes
> > uses extra RNG calls, so the actual call sequence won't be the same (and
> > will depend on N but nothing else).
> >
> > The second concern is that I'm worried my problem is going to take
> > forever with nested sampling. It's a somewhat high-dimensional problem -
> > 20-30 parameters - and the change in parameter volume from prior to
> > posterior is staggering: while the prior is a bit fuzzy, our knowledge
> > of (say) the inner orbital period goes from "about 1.6 days" to
> > "1.629401788(5) days"; many other parameters are similarly constrained.
> > Since nested sampling relies on gradually shrinking ellipses from the
> > entire space down to the target region, I worry that it will take a very
> > large number of steps (if the ellipse's volume shrinks by a factor 1.2
> > each time, that's ~3000 steps). This appears worryingly supported by a
> > numerical experiment I am running with a fast likelihood function that
> > nevertheless puts very tight constraints on the result.
> >
> > The third concern is about covariances. Of course ellipses are intended
> > to enclose potentially very skinny error regions, but I ran into
> > problems where my error region was so narrow that representing it with a
> > covariance matrix ran into matrix numerical headaches. I have
> > analytically marginalized out the worst offenders, but even the simple
> > problem that my parameters can be constrained on very different scales -
> > a sin i is known about a thousand times better than a cos i - can wreck
> > matrix algorithms. I guess I have to try this and see whether problems
> > arise.
> >
> > Currently I am working with emcee, which has its drawbacks, but can use
> > parallelism (to evaluate likelihoods for many walkers at once) and is
> > fairly robust against covariances (the point coordinates themselves are
> > used to generate candidates as linear combinations). But since I'm
> > trying to test a hypothesis - GR is better than not-GR - it sure would
> > be nice to use a tool that supports hypothesis testing!
> >
> > Thanks,
> > Anne
> >
> > On Tue, Sep 29, 2015 at 8:10 PM Kyle Barbary <kylebarbary at gmail.com
> > <mailto:kylebarbary at gmail.com>> wrote:
> >
> > Yes, possibly! Nestle currently implements the basic MultiNest
> > method, but doesn't implement later improvements such as importance
> > reweighting or polychord. I'm open to contributions and
> > improvements. (But be mindful of reading the MultiNest source code
> > due to licensing issues!)
> >
> > Best,
> > -- Kyle
> >
> > On Tue, Sep 29, 2015 at 1:03 PM, Johann Cohen-Tanugi
> > <johann.cohentanugi at gmail.com <mailto:johann.cohentanugi at gmail.com>>
> > wrote:
> >
> > likewise!
> > Any prospect toward the polychord extension? See
> > http://arxiv.org/abs/1506.00171v1
> > cheers,
> > Johann
> >
> >
> > On 09/29/2015 10:30 AM, Wolfgang Kerzendorf wrote:
> >> HI Kyle,
> >>
> >> Very nice. I'll definitely have a look at that.
> >>
> >> Cheers,
> >> Wolfgang
> >> --
> >> Dr. Wolfgang E Kerzendorf
> >> ESO Fellow
> >> European Southern Observatory
> >> Karl-Schwarzschild Str. 2, 85748
> >> Garching bei Muenchen, Germany
> >>
> >> On Tue, Sep 29, 2015 at 6:09 AM Kyle Barbary
> >> <<mailto:kylebarbary at gmail.com>kylebarbary at gmail.com
> >> <mailto:kylebarbary at gmail.com>> wrote:
> >>
> >> Hi all,
> >>
> >> I'm pleased to announce the initial release of Nestle, a
> >> small Python package for nested sampling. ("Nestle" rhymes
> >> with "wrestle".) Nested sampling is a statistical
> >> technique for parameter estimation and model comparison,
> >> commonly used in cosmology. We've been using it in the
> >> sncosmo package and have found it to be a robust global
> >> optimizer in addition to its more typically cited benefits.
> >>
> >> Nestle implements an algorithm similar to that used in the
> >> MultiNest software, but in an open-source (MIT) licensed
> >> and easy-to-install (pure Python) package. (It was written
> >> based only on the literature, not the MultiNest source
> >> code.) In addition to this algorithm, Nestle also
> >> implements the "classic" nested sampling algorithm and the
> >> "single ellipsoid" algorithm.
> >>
> >> Nestle depends on only numpy and (optionally) scipy and
> >> supports both Python 3 and Legacy Python (formerly known
> >> as Python 2).
> >>
> >> docs:
> >> <http://kbarbary.github.io/nestle>
> http://kbarbary.github.io/nestle
> >> source:
> >> <http://github.com/kbarbary/nestle>
> http://github.com/kbarbary/nestle
> >>
> >> I'd appreciate any feedback on this initial release,
> >> particularly about application to real-world problems and
> >> comparisons with results from MultiNest. Thanks!
> >>
> >> - Kyle
> >> _______________________________________________
> >> AstroPy mailing list
> >> AstroPy at scipy.org <mailto:AstroPy at scipy.org>
> >> https://mail.scipy.org/mailman/listinfo/astropy
> >>
> >>
> >>
> >> _______________________________________________
> >> AstroPy mailing list
> >> AstroPy at scipy.org <mailto:AstroPy at scipy.org>
> >> https://mail.scipy.org/mailman/listinfo/astropy
> >
> >
> > _______________________________________________
> > AstroPy mailing list
> > AstroPy at scipy.org <mailto:AstroPy at scipy.org>
> > https://mail.scipy.org/mailman/listinfo/astropy
> >
> >
> > _______________________________________________
> > AstroPy mailing list
> > AstroPy at scipy.org <mailto:AstroPy at scipy.org>
> > https://mail.scipy.org/mailman/listinfo/astropy
> >
> >
> >
> > _______________________________________________
> > AstroPy mailing list
> > AstroPy at scipy.org
> > https://mail.scipy.org/mailman/listinfo/astropy
> >
>
> --
> Scott M. Ransom Address: NRAO
> Phone: (434) 296-0320 520 Edgemont Rd.
> email: sransom at nrao.edu Charlottesville, VA 22903 USA
> GPG Fingerprint: 06A9 9553 78BE 16DB 407B FFCA 9BFA B6FF FFD3 2989
> _______________________________________________
> AstroPy mailing list
> AstroPy at scipy.org
> https://mail.scipy.org/mailman/listinfo/astropy
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20151009/03246573/attachment.html>
More information about the AstroPy
mailing list