[TheNetherWatcher]

Fixes #602.

compute_hr now raises a ValueError if qrs_inds is not strictly increasing, naming the first pair that isn't, for example:

ValueError: qrs_inds must be strictly increasing, but qrs_inds[1] = 8 is followed by qrs_inds[2] = 8

Before, repeated beats gave a ZeroDivisionError (lists) or inf with a RuntimeWarning (arrays), and beats out of order gave a negative heart rate. The docstring now says the indices must be strictly increasing and documents the error.

Tests: repeated, decreasing and repeated-last-beat inputs (lists and arrays) raise the error. pytest -m "not network" passes (103 tests), and the docs build passes.

[TheNetherWatcher]

Rebased onto main now that #601 is merged, so this only contains the new check. Tests pass.

[tompollard]

Thanks, this looks good! The error message naming the first bad pair is helpful.

One small suggestion: np.diff wraps around for unsigned integer arrays, so out-of-order beats aren't caught there. For example, np.array([2, 8, 5], dtype=np.uint32) passes the check and gives a meaningless heart rate. Comparing neighbours directly avoids this:

q = np.asarray(qrs_inds)
not_increasing = np.flatnonzero(q[1:] <= q[:-1])

Unsigned beat indices are unusual, so I'm happy to merge either way.

[TheNetherWatcher]

Good catch, thanks! I've switched to comparing neighbours directly, as you suggested, and added a test with np.array([2, 8, 5], dtype=np.uint32), which fails with the np.diff version. Tests pass (104).