[TheNetherWatcher]

correct_peaks is meant to search search_radius samples on both sides of each peak, but shift_peaks slices sig[ind - r : min(ind + r, sig_len - 1)]. That leaves out ind + r, and the last sample of the signal, so a peak there can't be found:

sig = np.zeros(30); sig[13] = 5; sig[29] = 5
processing.correct_peaks(sig, np.array([10]), search_radius=3, smooth_window_size=9, peak_dir="up")  # [7], expected [13]
processing.correct_peaks(sig, np.array([27]), search_radius=5, smooth_window_size=9, peak_dir="up")  # [22], expected [29]

Fix: slice up to min(ind + r + 1, sig_len).

Effect on record 100 (correct_peaks on the reference beats, XQRS and GQRS, radius 10, 36 and 61, all four peak_dir options):

• With the radius used in the existing test (61), only one peak moves, and only for peak_dir="down": the last beat, now on the final sample.
• With radius 10 on GQRS beats ("up", "both", "compare"), almost every peak moves one sample right, from ind + 9 to ind + 10. In all 2271 cases the new sample is higher in the smoothed-difference signal, so the old window was cutting off the maximum.
• The existing test_correct_peaks expectations are unchanged.
• XQRS and GQRS don't call correct_peaks, so their detections are unchanged.

This is the same kind of off-by-one as #572 / #573, but in shift_peaks rather than find_local_peaks. The two PRs touch different functions and don't depend on each other.

Tests: a peak exactly search_radius after the guess, and a peak on the last sample. The test fails on main. pytest -m "not network" and the docs build pass.

[tompollard]

Thanks, this looks good! The new slice matches the documented search radius, and the test fails on main.

While testing, I noticed a separate bug at the other end of the signal, in the "adjust early values" loop just below. When ind < search_radius, the window starts at 0, so argmax already gives the absolute index, but the loop subtracts search_radius - ind when it should add it. On main and on this branch:

sig = np.zeros(30); sig[0] = 5
processing.correct_peaks(sig, np.array([2]), 5, 9, "up")  # [-6], expected [0]
sig = np.zeros(30); sig[4] = 5
processing.correct_peaks(sig, np.array([2]), 5, 9, "up")  # [-2], expected [4]

That's not caused by this PR, so it can be a separate fix. Would you like to take it on?

[TheNetherWatcher]

Thanks for spotting that! Yes, I've opened #613 for it: the offset was subtracted instead of added, so flipping the sign fixes both of your examples. I also rebased this PR onto main after #601 was merged.

[tompollard]

looks great, thanks!