Volume branch

[segasai]

Getting rid of pointvolumes

[coveralls]

Pull Request Test Coverage Report for Build 936355285

• 57 of 61 (93.44%) changed or added relevant lines in 4 files are covered.
• 1 unchanged line in 1 file lost coverage.
• Overall coverage increased (+0.1%) to 77.259%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
py/dynesty/nestedsamplers.py	7	8	87.5%
py/dynesty/sampler.py	4	5	80.0%
py/dynesty/bounding.py	44	46	95.65%
<!--	Total:	57	61	93.44%	-->

Files with Coverage Reduction	New Missed Lines	%
py/dynesty/sampling.py	1	90.19%
<!--	Total:	1		-->

Totals
Change from base Build 919713254:	0.1%
Covered Lines:	3591
Relevant Lines:	4648

---

💛 - Coveralls

[segasai]

I think this is ready for review and merge. But I was also doing test, checking the behaviour of recovery of logz of arbitrary oriented elongated gaussian (with axis ratios of 1e-3:..:1) as a function of dimension. And this is the behaviour of rslice with multi bounds on xaxis is the ndim on the y-axis is the (logztrue - logzmeas)/logzerr

And the interesting thing is that there is a clear trend in the logz bias vs ndim that was present before.

And the volume change makes it somewhat worse. I'm suspecting that this must be connected to the ellispoidal splitting.

[joshspeagle]

Does this trend get better if the number of slices is increased, by chance (assuming you're not already doing that)? The auto-correlation times should scale as ~d^1-2, so the number of slices also would need to increase to help encourage effective sampling. In the initial slice this was imposed implicitly by iterating through all parameters, but this is not true for rslice.

I also agree that this is likely connected with the ellipsoidal splitting giving a (more reliable but possibly worse?) approximation of the overall distribution.

[joshspeagle]

Also, just going to ping #285 since that's likely the more appropriate area for continuing this discussion.