Deeper correctness & robustness fixes: known-peak indexing, unmixed-column order, interpeak split, infeasible bounds

[gchure]

Related issues: #8, #14, #15, #18, #19, #22 (the x0 is infeasible / degenerate-bounds family)

Summary

Four latent defects in Chromatogram that existing test data didn't exercise. Each fix ships with a regression test.

Fixes

I: known-peak indexing assumed the time axis starts at t = 0

scipy.signal.find_peaks returns positional indices into the current signal array, but _assign_windows mapped known_peaks to indices as np.int_(known / self._dt) — assuming t = 0 at index 0. On a chromatogram whose time axis starts at t0 ≠ 0 (or one cropped from a nonzero start), enforced peaks landed at the wrong index. The previous _crop_offset patch only worked when t0 = 0.

Fix: anchor the index math to the current frame's first time value t0 = self.df[self.time_col].values[0]. Numerically identical to the old code for the existing (uncropped, t0 ≈ 0) tests; correct for nonzero-start / cropped cases.

II: unmixed_chromatograms columns could be misaligned with peak_id

peak_df is sorted by retention_time (then peak_id = arange + 1), but the unmixed_chromatograms columns were filled in window/detection order. When a fit reorders peaks relative to detection order (e.g. a large skew shifting a retention time across a neighbor), show()'s unmixed_chromatograms[:, peak_id - 1] indexed the wrong column and mislabeled per-peak traces. (Aggregate sums elsewhere are order-independent.)

Fix: build the matrix directly from the sorted peak_df, so column i always corresponds to peak_id == i + 1. Values are identical to before; only ordering is corrected.

III: interpeak window split mishandled a gap at the first sample

_assign_windows skipped background-segment boundary construction when a background gap fell at the first sample (split_inds[0] == 0), which dropped the final background segment and mislabeled interpeak windows.

Fix: run the boundary logic for all multi-segment cases (elif split_inds[0] != 0: → else:). The leading single-point run is then correctly filtered by the existing len(rng) >= 10 check.

IV: rounded location guess could fall outside its bounds → x0 is infeasible

The location initial guess is the peak time rounded to _time_precision, while its bounds are the window's raw (unrounded) time range. Because _time_precision = ceil(|log10(dt)|) is coarse for small dt, rounding could push the guess just past the window max (e.g. 0.6052 → 0.61 > 0.6052), which scipy rejects as `x0` is infeasible. This is the residual still reproducible on the issue #15 data (sandbox/raw3.csv) after the v0.2.7 bound-widening — 8 windows hit it there.

Fix:

1. Clamp the location guess into its [lb, ub] before calling the optimizer (the true unrounded peak time is always inside the window, so this only undoes the rounding excursion). Verified: clears the x0 is infeasible crash on the ValueError: x0 is infeasible. error on fit peaks #15 data, which then fails only later with the legitimate "max function evaluations exceeded" outcome for genuinely undersampled data.

2. Add a safety net: before fitting, validate lb < ub and lb ≤ p0 ≤ ub for every parameter and raise an actionable message naming the retention time and offending parameter — instead of scipy's opaque error. This also covers the theoretical degenerate-amplitude / single-point-window cases.

Tests

• test_known_peaks_nonzero_start_time — fails on main, passes here.
• test_unmixed_columns_match_peak_id — fails on main, passes here.
• test_infeasible_location_guess_does_not_crash — fails on main with x0 is infeasible, passes here. Fixture: test_infeasible_bounds_chrom.csv (the issue ValueError: x0 is infeasible. error on fit peaks #15 chromatogram).
• test_peak_adjacent_to_start_assigns_interpeak — smoke test. The exact split_inds[0] == 0 branch can't be triggered deterministically without coupling to scipy.peak_widths internals, so this guards the surrounding end-to-end behavior rather than isolating the branch. (A fragile internals-coupled test would be a liability; the fix itself is a provably-correct one-line change.)

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 97.15%. Comparing base (026596d) to head (6998021).

Additional details and impacted files

@@            Coverage Diff             @@
##             main      #28      +/-   ##
==========================================
+ Coverage   97.12%   97.15%   +0.03%     
==========================================
  Files           3        3              
  Lines         557      563       +6     
==========================================
+ Hits          541      547       +6     
  Misses         16       16              

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

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.