RESULT-CHANGING for the GPU spot finder (classic and adaptive, which shares this kernel for its
local-box passes) - only on pixels where the two used to disagree.
Two differences between pixel_result and the CPU's StrongInWindow:
- SNR test. Both form T = float(var) * strong2 in float. The CPU compares the int64 square
(in_minus_mean)^2 with (int64) ceil(T); the GPU compared it with T directly, which converts the
square to float. Below 2^24 the two differ only when the square equals ceil(T) with T not an
integer (an exact-integer strong2 such as 9 or 16 never gives that); past 2^24, where T is an
integer, the GPU's rounded square can land on T and fail a pixel the CPU accepts. The GPU now
uses the CPU's integer-vs-ceil comparison.
- Count threshold. At photon_count_threshold = 0 the CPU still requires val > 0; the GPU took 0 as
"no threshold". It matters only for a pixel <= 0 above a negative local mean (a
pedestal-subtracted detector); the adaptive finder always runs this pass with threshold 0. The GPU
now applies val > threshold unconditionally, with the threshold carried as int64 like the setting.
Measured: a diagnostic build evaluating both semantics in every pixel_result found zero
disagreements in ~2e10 first-pass and ~2.9e7 candidate tests over lyso_x06da_ref, cytc_x10sa,
myob_x10sa, yag_x10sa_20keV, 4nwv and thau_bl1a_3p8keV (JUNGFRAU); the battery GPU runs before and
after give bit-identical p.hkl on all six sets. The new knife-edge test constructs both cases (a
checkerboard window whose square is var * 25 exactly and rounds onto the float threshold; a 0 above
a negative checkerboard) and failed on the GPU before this change.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PXc1zD1yxHqaR1DGdCTHL4
leonarski_fandClaude Opus 5.5
9c4e22465a