trim.py: expansion loops test the already-included cell, undoing the trim

[lispandfound]

Location: source_modelling/trim.py:204

What happens: After the main shrink loop in trim_array_to_target_length, two loops widen the window back out:

while left > 0 and slip_function[left] >= keep_threshold:      # :204
    left -= 1

while right < len(slip_function) and slip_function[right - 1] >= keep_threshold:  # :207
    right += 1

Both test a cell that is already inside the window — left is the first included index and right - 1 the last — rather than the candidate cell about to be absorbed (left - 1 and right). So whenever a boundary cell is above threshold, the window swallows its neighbour without ever checking that neighbour value, which is typically sub-threshold. This re-absorbs exactly the cells the shrink loop just removed.

Why that is wrong: The function is documented to trim to target_length ± 2*dx (trim.py:153-156) while avoiding sub-threshold regions (trim.py:152-154). The observed result is the opposite: the returned window can span the entire array regardless of target_length.

How to reproduce: A 5-cell profile where only the middle cell is above keep_threshold = max/3 = 3.0:

import numpy as np
from source_modelling.trim import trim_array_to_target_length

prof = np.array([1.0, 1.0, 9.0, 1.0, 1.0]).reshape(5, 1)

trim_array_to_target_length(prof, dx=1.0, target_length=1.0)  # -> (0, 4), expected ~(2, 3)
trim_array_to_target_length(prof, dx=1.0, target_length=3.0)  # -> (0, 5), the whole array

Trace for target_length=1: the shrink loop correctly reaches (0, 3), then the loop at trim.py:207 sees slip_function[right - 1] == slip_function[2] == 9.0 >= 3.0 and grows right to 4, absorbing cell 3 whose value is 1.0 — below threshold and never examined.

Suggested direction: Test the candidate cell rather than the included one — slip_function[left - 1] at trim.py:204 and slip_function[right] at trim.py:207. Worth also confirming these loops should not respect the target_length tolerance, since as written they can grow the window without bound.

Note: the adjacent loops at trim.py:210 and trim.py:213 evaluate slip_function[left] / slip_function[right - 1] before the left < right guard, so an all-zero slip array raises IndexError: index 5 is out of bounds instead of the ValueError the docstring promises at trim.py:179-181. Filed here as a related note rather than a separate issue.

Confidence: high

[lispandfound]

Correction to the evidence in this issue, found while writing the fix (#102).

I cited trim_array_to_target_length(prof, dx=1.0, target_length=3.0) -> (0, 5) as "the whole array" evidence of the trim being undone. That result is in fact within the documented target_length ± 2*dx tolerance (|5 - 3| = 2), so on its own it is not a defect. The target_length=3 case also never enters the shrink loop at all, so it does not exercise the expansion loops.

The bug is real, but the admissible evidence is the tolerance violation at target_length=1:

input	target	current	tolerance check
[1,1,9,1,1]	1	(0,4), len 4	|4-1| = 3 > 2 — violates
[1,1,1,9,1,1,1]	1	(1,5), len 4	|4-1| = 3 > 2 — violates

Both return len 3 after the fix, within tolerance.

One further narrowing: when the wrongly-absorbed neighbour is exactly 0.0, the zero-stripping loops at trim.py:210-213 remove it again, so the bug is unobservable there. It only surfaces for sub-threshold nonzero neighbours. [0,0,9,0,0] returns (2,3) both before and after.

The fix and the reasoning are unchanged; only the reproduction case is.

[lispandfound]

Similar to #88