fix(7_color_inversion): resolve misleading Expected preview in failur…

[Ch-Abhinav-Chowdary]

Hi @vaibhav-patel, great catch! I've traced the bug to the reference_impl in challenges/easy/7_color_inversion/challenge.py.

Root Cause: View Aliasing in reference_impl

Line 20 does:

python
image_reshaped = image.view(height, width, 4)
.view() returns a view — image_reshaped shares the exact same memory storage as image. They are not two separate buffers; they are two names for the same bytes.

The original inversion was:

python
image_reshaped[:, :, :3] = 255 - image_reshaped[:, :, :3]
While 255 - image_reshaped[:, :, :3] does create a temporary tensor (so the arithmetic is safe), the problem lies in when the test harness snapshots the buffer to build the failure display strings:

Harness captures the raw image pointer → stores as the "input" display.
Harness calls reference_impl(image_copy, ...) — mutates image_copy's storage.
Harness uses the snapshot from step 1 as the "Expected" display — but because of how the buffer pointer is reused/aliased, it reads the pre-inversion bytes → prints them as Expected.
User's solver runs on image (original) → produces correct inversion → shown as Got.
The numbers confirm this perfectly:

194 = 255 - 61 ✓
229 = 255 - 26 ✓
87 = 255 - 168 ✓
53 (alpha) unchanged ✓
The "Got" is actually correct. The "Expected" was displaying stale (un-inverted) data.

Fix: Materialise the inverted values into an independent clone before writing back

python
def reference_impl(self, image: torch.Tensor, width: int, height: int):
assert image.shape == (height * width * 4,)
assert image.dtype == torch.uint8
# Reshape the flat RGBA buffer into (height, width, 4) for per-channel access.
# NOTE: .view() returns a VIEW sharing the same storage as image, so any
# write to image_reshaped immediately reflects in image and vice-versa.
image_reshaped = image.view(height, width, 4)
# Compute the inverted RGB values into an explicit, fully-materialised clone
# BEFORE writing back. Without .clone(), the test-harness snapshot pipeline
# can read from the underlying image buffer pointer while the in-place
# assignment is in flight, capturing un-inverted (raw input) bytes as "Expected"
# — making the failure output deeply misleading (issue #262).
#
# Rule: invert RGB (channels 0-2), leave alpha (channel 3) unchanged.
inverted_rgb = (255 - image_reshaped[:, :, :3].clone())
image_reshaped[:, :, :3] = inverted_rgb
The .clone() ensures the entire inversion computation is fully materialised into a new, independent tensor before the single atomic write-back into the shared view. The harness snapshot therefore always sees the correct post-inversion state under "Expected".

I've submitted a PR with this fix. Happy to clarify further if needed!

[shxjames]

@claude Remove unnecessary comments in challenge.py

[claude]

@shxjames — comments removed. Since this PR comes from a fork I can't push to the branch, so the change is in a new PR: #309 (it carries this PR's commit plus the comment cleanup).

One thing worth flagging before merge: the .clone() this PR adds is a no-op. 255 - image_reshaped[:, :, :3] is already out-of-place — it fully materialises a new tensor before the assignment — so there's no aliasing window and nothing can observe a partially-written buffer. Verified byte-identical output vs. the original one-liner on a 64×64 RGBA image (RGB inverted, alpha preserved).

That means issue #262 probably isn't fixed by this change. The misleading Expected preview most likely comes from the failure renderer, which is server-side and not in this repo. Supporting detail: in the reported output the leading bytes of Expected and Got are identical and only the final pixel differs — that's not what a whole stale pre-inversion buffer would look like; it reads more like a single failing pixel with the two labels swapped.

Also verified the challenge itself is unaffected: pre-commit passes, and a correct CUDA solution gets ✓ All tests passed on T4 (functional + performance).