Repository navigation
reduce lineardiff convex problem to 2 * order variables via thin QR #237
Description
lineardiff solves, per window of length
where order). It reduces exactly to a
Derivation
Thin QR:
using
The data enter only through *obs, zero whole rows of
Why not the Gram form. Expanding gives
Column scaling. CVXPY canonicalizes user_limit with wrong coefficients. Let
where
The total is still
Consequences
- Caching: the problem shape depends only on
order, so_PROBLEM_CACHEcan be keyed byorderalone instead of also depending on window length. The 64-entry clear and the separateB_pparameter both go away. Currently truncated edge windows add ~11 keys per run, at 10–25 ms of canonicalization each, also incurred for everywindow_sizetried inoptimize. - Prototype: tests pass, including equivariance; outputs agree to ~1e-9; one run is ~1.3× faster. The gain is small because CVXPY's fixed per-call overhead (~1.7 ms) dominates.
Filed by Claude (Claude Code) on behalf of @pavelkomarov.
Activity
[-]lineardiff: reduce the convex problem to 2*order variables via thin QR[/-][+]reduce `lineardiff` convex problem to 2 * `order` variables via thin QR[/+]pavelkomarov commentedon Sep 21, 2026
I could have Claude just go bang this one out. It discovered the opportunity, and I vaguely follow the math. The trick is doing it elegantly in the code, so the reduction from the present problem form is clear, so the number of named things to juggle is minimal, so the sequence of operations makes sense. I don't trust Claude not to make a tangle of it, even though I'm sure it would be correct. It doesn't seem to understand that having an amazingly wide field of attention shouldn't be a license to overcomplicate things. We probably need a big block comment containing some of the math above, but way less verbose than what Claude would write, as well as precise comments attached to lines to keep readers attuned to what's happening and why. Essentially, I want it to have human attention. The way I'd go about it is have Claude draft it, then refine refine refine, which is kind of exhausting, albeit fast, to keep running to catch up. It does result in deepened understanding and a cleaner, leaner product. But I don't want to take this on at the moment. I'm not in the mood, having done dozens of others recently. I just want the code to be stable, and this is purely a runtime optimization based on overly-clever math.