Add weight support for eff calculation

[dkobylianskii]

Summary

This pull request introduces the following changes

• Improve the efficiency of the efficiency calculation
• Add weight support
• Fix possible input issue with IntegratedEff plot

Relates to the following issues

• 197

Conformity

• [x] Changelog entry
• [x] Documentation

[codecov-commenter]

Codecov Report

Merging #206 (6b1e192) into main (27971ea) will increase coverage by 0.00%. The diff coverage is 100.00%.

@@           Coverage Diff           @@
##             main     #206   +/-   ##
=======================================
  Coverage   97.15%   97.16%           
=======================================
  Files          35       35           
  Lines        3165     3171    +6     
=======================================
+ Hits         3075     3081    +6     
  Misses         90       90           

Files Changed	Coverage Δ
puma/integrated_eff.py	94.73% <100.00%> (ø)
puma/metrics.py	98.41% <100.00%> (+0.16%)	:arrow_up:
puma/tests/test_metrics.py	100.00% <100.00%> (ø)

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more

[dguest]

Minor commnets:

• The function has a help string that says "calculates efficiency", but it calculates the background efficiency for a given signal efficiency target, right? (not really a problem, I just had to read the code to understand what was going on)
• This implementation might be better than the one I imagined 😀. You loop over the data twice: once with the fancy wikipedia thing (to get the cut values), and again to get the background efficiency at those values. I was imagining that you'd first make a signal histogram with a few thousand evenly spaced bins, then use the bin edges and efficiencies to interpolate the cut values, then make another histogram with the background and interpolate the efficiency there again. I think both might have advantages:
  • Your way is certainly more exact.
  • My way might be faster: there's no sorting, just three loops over the data (to get the bounds, the signal histogram, and the background histogram).
  • Your way doesn't trivially extend to huge datasets that don't fit in memory. Histograms are pretty trivial to extend this way, but given that the function takes an array anyway reworking the internals can't solve this.

Anyway unless people are regularly running out of memory this seems like a big improvement: hopefully at least making a ROC with 1000 cut values is much faster with this.

[samvanstroud]

As far as I know no one has had memory issues with jet-wise stuff yet :D

[dkobylianskii]

Hi @dguest, @samvanstroud ,

I checked the speed, we have 100 times improvement for 1e6 jets and 1e3 cuts :) In the ROC class, we use recalculated rejection values, so there is no need to add weights there.

[samvanstroud]

@dkobylianskii thanks!