Fix trim expansion loops testing the already-included cell - #102
Open
lispandfound wants to merge 1 commit into
Open
Fix trim expansion loops testing the already-included cell#102lispandfound wants to merge 1 commit into
lispandfound wants to merge 1 commit into
Conversation
The two expansion loops in trim_array_to_target_length tested slip_function[left] and slip_function[right - 1] -- cells already inside the window -- rather than the candidate cells left - 1 and right. A boundary cell above the keep threshold therefore pulled in its neighbour without that neighbour ever being examined, widening the returned window past the documented target_length +/- 2 * dx tolerance. For [1, 1, 9, 1, 1] with target_length=1 and dx=1 the function returned (0, 4) -- a 4-cell window for a 1-cell target, |4 - 1| = 3 > 2 -- where it now returns (0, 3). Fixes #86 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #86
Problem
The two expansion loops in
trim_array_to_target_lengthtested a cell that is already inside the window rather than the candidate cell about to be absorbed:So whenever a boundary cell was above
keep_threshold, the window swallowed its neighbour without ever checking that neighbour — typically a sub-threshold cell the shrink loop had just removed.Measured impact
±2*dx)[1,1,9,1,1](0,4)len 4(0,3)len 3[1,1,1,9,1,1,1](1,5)len 4(1,4)len 3[0,0,9,0,0](2,3)(2,3)Trace for the first case: the shrink loop correctly reaches
(0, 3), then the second expansion loop seesslip_function[right - 1] == slip_function[2] == 9.0 >= 3.0and growsrightto 4, absorbing cell 3 whose value is1.0— below the threshold and never examined.Correction to the issue as filed
Issue #86 cited
[1,1,9,1,1]withtarget_length=3returning(0, 5)— "the whole array" — as evidence. That result is actually within the documentedtarget_length ± 2*dxtolerance (|5-3| = 2), so it is not by itself a defect; I have noted that on the issue. The tolerance violation attarget_length=1above is the real evidence, and it is what the new test asserts.Cases where the absorbed cell is exactly zero are also not observable, because the zero-stripping loops further down clean them up. The bug only shows with sub-threshold but nonzero neighbours.
Changes
source_modelling/trim.py— testslip_function[left - 1]andslip_function[right], the cells actually being considered.tests/test_trim.py— addtest_trim_expansion_does_not_absorb_sub_threshold_cells, asserting both the exact window and the documented tolerance.Verification
pytest tests/test_trim.py— 12 passed.ruff check,ruff format,numpydoc lintclean.Note this touches the same function as #88 (the bounds-guard ordering a few lines below), so those two branches will want a trivial rebase depending on merge order.
🤖 Generated with Claude Code