Skip to content

SemanticCompute v1.15.0

Choose a tag to compare

@entertrainment entertrainment released this 01 Sep 17:41

SemanticCompute v1.15.0 — Savitzky–Golay, and two kinds of honesty about drift

A minor, by the rule: one additive family (catalogue 158 → 159), one latent GPU bug fixed before any
consumer could hit it, and a documentation-drift class killed with a gate after a consumer caught it.

Added

Savitzky–Golay smooth/derivative — batched, with POLYNOMIAL-CONSISTENT edges. The natural companion
to the Hampel identifier already in the catalogue: Hampel rejects the spikes a polynomial fit would
chase, S–G preserves the peaks Hampel leaves noisy; robust smoothing is the composition, no fused
kernel required.

  • The requesting consumer's own analysis had correctly ruled the single-signal interior "Correlation
    with time-reversed taps — never a gap". What no family covered: the EDGES (a different weight row at
    each boundary position — the window's own least-squares fit evaluated off-centre, not a fixed-tap
    correlation) and the batch fused with them.
  • The edge policy is pinned by the test that matters: a ramp's first derivative is exact at sample 0,
    where the common reflection convention collapses it toward zero — the mirror makes the boundary look
    locally symmetric precisely when a trend detector needs the slope most.
  • Degree-≤p polynomials pass through EXACTLY, edges included. Derivative scaling is d!/hᵈ with the
    sample step a real parameter. Weight rows sum to 1 (smoothing) or 0 (derivatives), asserted at design
    time. Measured: 1.85× peak retention versus a same-width boxcar.
  • Adopted by the FIRFilters package as a test-only oracle: its independently coded S–G design is held
    against the family (centre weights across a design grid, every interior output), and the edge-policy
    difference is asserted AS A FACT — with a sentinel that fires if the two conventions ever silently
    converge.

Fixed

  • ResamplePolyphase's GPU kernel could overflow its position producti·M in 32-bit overflows
    once outCount·M exceeds 2³² (a long file at a large reduced M). The CPU reference always used 64-bit
    positions, so the two sides were identical only until the file got long. Found while wiring the
    consumer estate; the kernel now computes positions in ulong, parity re-verified unchanged.
  • The README family table had rotted to misinformation — a consumer diffing sc_list_families
    against it found 141 of 158 canonical names absent. Regenerated mechanically from the catalogue and
    GATED (ReadmeFamilyTableSyncTests: every name verbatim, stated count matches) so it cannot rot
    again. The landing page's live-surface numbers were trued in the same sweep and its release chips
    pinned to their true versions.

Verification surface: 1,172 tests in 253 suites; the kernel-compile sweep covers 361 programs across
220 lowerings, 0 failed. Four lowering targets, three executed in-core (Metal, portable C, WGSL) plus
the externally verified CUDA runner.