PTsampler is removed

[andyfaff]

Hi, I was wondering why the PTSampler has been removed from the master branch of emcee and forked to ptemcee? I maintain a package that uses both samplers and it's going to be more maintenance work to continue to use both.

[andyfaff]

What I'm mainly concerned about is the following:

• will ptemceeretain the same call signatures/internals as emcee.ptsampler? I'd like my code to be able to cope with both alternatives without a great deal of effort. For example, if the sampler attributes are going to be refactored, then this would create a mismatch between the two.
• to what extent is ptemcee going to be maintained?

Also, what's the likely release date for the next version of emcee?

@willvousden

[andyfaff]

I've just been investigating the constructor for emcee.PTSampler and ptemcee.sampler.Sampler, the signatures differ. In the former ntemps is the first positional argument. In the latter it's a kwd argument. This is an example of the divergence I was mentioning.

(BTW, thank you for emcee - I appreciate the package and like how it works, which is why it's a dependency for my own work)

[dfm]

I hope that in hindsight you'll be able to recognize the irony in what you're saying...

I didn't write the PTSampler in the first place and I've been cursing myself for merging it since the beginning because of the expectation that I continue to support it even though I don't use it. Many (most?) bug reports here and offline were related to the PTSampler and that's not because more people are using it. I don't have the time or energy to support that part of the sampler anymore (just like you, I don't want to burden myself with extra busywork) so instead of continuing to just let it fester, now's the time to cut it loose. @willvousden has done some awesome work improving on the original method. If you have issues with the interface, those should be opened on the ptemcee repo, not here.

I'm hoping to release v3.0 in the next week or so, but you know how these things go.

[andyfaff]

It's good to know the history. As an OSD I know the effort that goes into maintaining packages, in addition to doing the day job, so thank you. The transition would've been easier with a deprecation cycle - at the moment ptemcee is not installable on Windows. I've submitted an issue and PR on the project, so I have my fingers crossed.

It'll be interesting to try the new features in emcee (e.g. the moves kwd). Whilst you're probably aware of it, the docstring for EnsembleSampler needs updating. moves and backend aren't described. Also, the a kwd is not used in initialising the EnsembleSampler object.

[dfm]

Thanks. Yeah - I hear you about having a deprecation cycle, but this is a big enough re-write that it was going to be too much work to try to keep the PTSampler compatible. I'd been putting off a release for exactly that reason.

I'm in the process of re-writing all the docs and docstrings so thanks for the heads up, but I am aware :-)

[andyfaff]

No worries.

The rationale for using PTSampler was that it's able to sample multimodal distributions. Do you have any pointers for how much better PTSampler is than bog-standard emcee for that job, and do the new moves ameliorate that?

[dfm]

The moves will possibly help. The KDEMove is based on the kombine sampler that was designed for multimodal sampling. It's not as fully featured as their sampler, but I've had some success for reasonably low dimensional (<10) multimodal problems. You can never really guarantee reliable MCMC performance with multimodal densities though - not even with parallel tempering.

[willvousden]

Hi both.

Working out where to put a parallel tempered version of emcee was a tricky thing. It's similar enough that it looks like it should be a specialisation of the original sampler, but in the end you end up duplicating almost all of its internals, hence why it was forked to ptemcee.

I haven't had much time for ptemcee for a while now (largely because I don't use it much at the moment). That said, I'll to try and whip it into shape, and I'm very happy to take PRs. I agree that it it should share emcee's interface if possible (that was the original intention, anyway).

[willvousden]

As for the efficacy of parallel tempering in sampling multimodal distributions, it's generally helpful, but you have to be careful. One of the things we found in developing ptemcee is that inter-temperature communication breaks down for some multimodal likelihoods (akin to thermodynamic phase transitions), no matter what temperature ladder you choose. The paper has details.

[andyfaff]

I'm happy to help with any PRs. What helps these projects helps mine.

On 20 Oct 2017 9:24 am, "Will Vousden" notifications@github.com wrote:

As for the efficacy of parallel tempering in sampling multimodal distributions, it's generally helpful, but you have to be careful. One of the things we found in developing ptemcee is that inter-temperature communication breaks down for some multimodal likelihoods (akin to thermodynamic phase transitions), no matter what temperature ladder you choose. The paper http://arxiv.org/abs/1501.05823 has details.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/dfm/emcee/issues/236#issuecomment-338055047, or mute the thread https://github.com/notifications/unsubscribe-auth/AAq51oaEi-IW68Lsdd2731vREl8SpVeTks5st8w6gaJpZM4P87Nu .

[Gabriel-p]

So, we should not be using the PTSampler from emcee anymore, right? Does ptemcee have any available docs? There's this http://ptemcee.readthedocs.io/en/latest/ but it's empty... The repo is also somewhat lacking in details (installing, examples, useful cases, etc.).

[andyfaff]

@Gabriel-p, that's the case, PTSampler won't be in emcee3. I'm not sure what docs there are for ptemcee, apart from the docstring.