[TheNetherWatcher]

compare_annotations can match one test annotation to two reference annotations:

c = processing.compare_annotations(np.array([0, 2, 4, 5]), np.array([1, 5]), window_width=6)
c.matching_sample_nums  # [0, -1, 0, 1]: test annotation 0 is used twice
c.fp, c.positive_predictivity  # -1, 1.5

When a reference annotation loses a contested test annotation to the next reference, compare falls back to the previous test annotation. It only checks that the previous reference didn't take it, so if that reference was unmatched, a test annotation matched earlier on can be matched again.

Fix: keep track of the last matched test annotation. Matches are made in increasing order, so the fallback is used only if it comes after that one. This replaces the old check (which it covers).

Checking that nothing else changes:

• On 200,000 random small cases, the new code gives exactly the same matches as main whenever main doesn't match a test annotation twice (about 6% of the cases did). With the fix, none do.
• On record 100 (gqrs and xqrs against the reference beats, two window sizes), the matches are identical.

Tests: the example above, plus a randomized check that matches are unique, in order and within the window, and that fp is never negative. Both fail on main. pytest -m "not network" and the docs build pass.

This is separate from #566, which handles empty inputs in _calc_stats.

[tompollard]

Thanks, this looks good, and the explanation of the fallback made it easy to follow!

I ran my own comparison with wider windows (50,000 random cases, windows up to 30 samples). main matched a test annotation twice in about 18% of them, which can make fp negative and positive predictivity greater than 1. With this PR there were none, and every case where main was already correct gave identical matches. Record 100 with xqrs_detect is unchanged too.

[tompollard]

Sorry, another conflict on changes.rst. This will be a continued annoyance so perhaps we need a better way of dealing with the file.

[TheNetherWatcher]

lol yes, will see this

[TheNetherWatcher]

Moved each changelog entry next to a related one instead of all at the end, so the open PRs shouldn't conflict with each other anymore, whatever order they go in.

Longer term, one file per change (like towncrier) would avoid this entirely. Happy to set that up if you want.

[tompollard]

For the longer term, one option is a file per change (for example docs/changes/606.rst), combined into changes.rst at release time, as towncrier does.

Thanks again @TheNetherWatcher. I don't know towncrier, but it sounds like a good idea to me.

[TheNetherWatcher]

Nice, I'll put together a small PR for it once these are in, so it doesn't clash with them.