Date: 2026-06-06
Time: 15:14
apply-operations-to-an-array/solution.pyThis file is a self-contained solution to LeetCode 2460: Apply Operations to an Array. It owns both the algorithm implementation and its test suite. Within the leetcode-implementations repo, each problem directory follows this same pattern — solution.py holds the canonical solution plus inline unit tests.
performOps(nums: list[int]) -> list[int] — The sole public function. Takes a list of non-negative integers, applies pairwise doubling operations, then moves all zeros to the end. Returns a new list (the input is not mutated, since result = nums[:] copies first).
TestPerformOps — Eight test cases covering the contract: LeetCode examples, edge cases (all zeros, no duplicates, single pair), and tricky sequential interactions (consecutive triples, all-same, zeros between values).
The solution uses a classic two-phase in-place transformation:
1. Phase 1 (lines 16–19): Single left-to-right pass. When adjacent elements are equal, double the left one and zero the right. This is sequential and order-dependent — the result of processing index i affects what index i+1 sees.
2. Phase 2 (lines 22–27): The "move zeros to end" idiom, implemented via a write-pointer compaction. Non-zero values are packed to the front using a write index, then trailing positions are filled with zeros. This is the same algorithm as LeetCode 283 (Move Zeroes).
The file bundles tests with the solution rather than importing from a separate test file, though test_solution.py also exists and imports from here.
Imports: Only unittest from the standard library — no external dependencies.
Imported by: The test_solution.py in this directory imports performOps. The massive "Imported By" list in the prompt is misleading — those are *other* problems' test files that follow the same structural pattern, not actual importers of this specific function.
Given input [1, 2, 2, 1, 1, 0]:
1. Copy: result = [1, 2, 2, 1, 1, 0]
2. Phase 1 iteration:
i=0: 1 ≠ 2, skipi=1: 2 == 2 → result = [1, 4, 0, 1, 1, 0]i=2: 0 ≠ 1, skipi=3: 1 == 1 → result = [1, 4, 0, 2, 0, 0]i=4: 0 ≠ 0? No, 0 == 0 → result = [1, 4, 0, 2, 0, 0] (doubling zero is still zero)3. Phase 2 compaction: [1, 4, 2, 0, 0, 0]
nums[:] creates a shallow copy on line 14.i+1 is zeroed before index i+1 is examined as the left element of the next pair. This means [2, 2, 2] produces [4, 0, 2] (not [4, 0, 4]) — the zeroed middle element doesn't match the third element.result[i] == result[i+1] == 0, doubling zero is still zero and setting the next to zero is idempotent. The algorithm handles this correctly without a special case.None — the function assumes valid input per the LeetCode contract (non-negative integers, length ≥ 1). No bounds checking or type validation. The unittest runner is the only error surface, and it uses standard assertEqual assertions.
apply-operations-to-an-array/test_solution.py — How the external test file imports and exercises performOps, and whether it adds coverage beyond the inline testsmove-zeroes/solution.py — The standalone version of Phase 2's zero-compaction algorithm, likely using the same write-pointer techniquesequential-pairwise-operations — How left-to-right order dependency in Phase 1 creates subtle behavior (e.g., triple-element cascades) that differs from a simultaneous-application modelapply-operations-to-an-array/review.md — The code review notes for this solution, which may flag alternative approaches or complexity analysisapply-ops-nonmutating — performOps copies the input with nums[:] and never modifies the original listapply-ops-phase-order — Phase 1 (pairwise doubling) must execute fully before Phase 2 (zero compaction); reversing or interleaving them produces incorrect resultsapply-ops-left-to-right-dependency — Phase 1 processes pairs left-to-right, so zeroing result[i+1] affects the comparison at index i+1 vs i+2 in the next iterationapply-ops-zero-doubling-noop — Adjacent zeros trigger the doubling branch but produce no observable change (0*2=0, set next to 0), so no special-casing is needed