stop warning when logL==logL_birth==-inf

[lukashergt]

Currently we issue a warning when logL<=logL_birth, which includes the case logL==logL_birth==-inf. The latter has come up a number of times in my latest runs, spamming me with warnings, which ultimately are nothing to worry about.

This little PR silences this particular warning when logL==logL_birth==-inf is the only occurrence of logL<=logL_birth.

Checklist:

• I have performed a self-review of my own code
• My code is PEP8 compliant (flake8 anesthetic tests)
• My code contains compliant docstrings (pydocstyle --convention=numpy anesthetic)
• New and existing unit tests pass locally with my changes (python -m pytest)
• I have added tests that prove my fix is effective or that my feature works
• I have appropriately incremented the semantic version number in both README.rst and anesthetic/_version.py

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 100.00%. Comparing base (b4b9d46) to head (ac7f81f).
Report is 1 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff            @@
##            master      #395   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files           36        36           
  Lines         3058      3060    +2     
=========================================
+ Hits          3058      3060    +2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[AdamOrmondroyd]

Code changes are simple enough that I'm happy, but I wanted to ask what your use case is?

[lukashergt]

Code changes are simple enough that I'm happy, but I wanted to ask what your use case is?

I have a bunch of PolyChord runs that produce rows with 0 weight, -inf loglikelihood, and 0 in all parameters (I believe this might have to do with the synchronous vs asynchronous PolyChord setup). A uniqueness check in anesthetic reduces these rows to a single one, which ultimately gets dropped alongside throwing this warning.

These rows are not really a problem (since they have zero weight), so they can be dropped without a problem, and should not need the warning. The warning was created for situations of logL_birth > logL, which comes up during importance sampling with a new likelihood.

[AdamOrmondroyd]

lgtm