[Sad Catapella N3][Validation] Low-level normalization.apply accepts reversed clipping and integer output dtypes silently #39

Baseline and classification

Batch 3 at f784c95e3049483f87466150ffc5764375fa631d. Confirmed discrepancy between documented API and argument validation, with isolated NumPy probes (not repository tests).

Evidence

• NormalizationParameters.apply lines 41–63 documents dtype as a floating-point result type and clip as a lower/upper interval, but passes both through with no validation. np.clip(result, low, high) with low > high collapses output to high; .astype(np.uint8) converts normalized real values to integers (negative values can wrap).
• Tests cover valid clip=(0,1) and dtype=np.float64 but not invalid dtype/clipping choices.

Minimal examples

NormalizationParameters('z-score',0.,1.).apply(np.array([-1.,0.,1.]),clip=(1.,0.)) returns a constant zero array instead of refusing reversed clip; using dtype=np.uint8 maps negative normalized results to wrapped bytes. An isolated NumPy probe reproduced these operations; the package functions themselves were not run.

Fix/acceptance

Validate a two-element finite clip tuple with low ≤ high; document whether equal endpoints are allowed. Validate output dtype as supported floating-point (prefer float32/float64 explicitly) and reject bool/integer/object/complex. Keep input untouched and nonfinite-input semantics unchanged. Add direct API tests and compare with Parameters.apply contract (fixed float32). No Numba benefit.