Skip to content

Tooling: 2.03× faster parity-side basis/contains with identical receipts - #1861

Open
VictorLiwentao wants to merge 2 commits into
CrocSwap:mainfrom
VictorLiwentao:cursor/parity-side-basis-cache-60b9
Open

VictorLiwentao wants to merge 2 commits into
CrocSwap:mainfrom
VictorLiwentao:cursor/parity-side-basis-cache-60b9

Conversation

@VictorLiwentao

Copy link
Copy Markdown
Contributor

Change and scope

At base 0b1cccf86e2f5132ed286a26ef0a681a495740ea, the historical parity-side audit spends most time in scripts/binary_phase_frames.py: basis and contains are called millions of times, and contains previously rebuilt basis(space) twice per membership test.

This PR memoizes basis on the row tuple and implements contains by reducing the vector against one basis of the space. The highest-bit pivot rule, elimination order, classify/nullspace/residual APIs and every Boolean result are unchanged. Only the source pin for scripts/binary_phase_frames.py changes inside the three certificates that bind that file (parity-side, disjoint-tensor-compression, dyadic-central-factor).

Tooling improvement; no new kappa. Selected frontier untouched.

Result

On Linux / CPython 3.12.3, five alternating fresh-process pairs of the full h=8,10,26 stream gave median 27.349 → 13.463 s (2.03×). Timing is host-descriptive and is not a correctness gate. Every experiment receipt matches the baseline checker fieldwise.

Package: research/parity-side-basis-cache/.

Validation

python3.12 -I -B research/parity-side-basis-cache/verify.py
python3.12 -I -O -B research/parity-side-basis-cache/verify.py
python3.12 -B scripts/research_package.py --package research/parity-side-basis-cache
python3.12 -I -B research/parity-side-basis-cache/benchmark.py --rounds 5

Expected:

PASS_PARITY_SIDE_BASIS_CACHE h=[8, 10, 26] roles=[724, 2271, 82720] repaired=[938, 3283, 308336] ... no_new_kappa
PASS_REGISTERED_RESEARCH_PACKAGE research/parity-side-basis-cache outcome=completed
PASS_IDENTICAL_PARITY_SIDE_RECEIPTS

Default verify is read-only. Full make verify, selected cold replay, Lean, and multiplication-theorem obligations were not rerun for this isolated historical-checker change.

Overlap and credit

Closest priors (different objects): CrocSwap/integer-mult-bounds#756, CrocSwap/integer-mult-bounds#1793, CrocSwap/integer-mult-bounds#1217. No competing open PR on this object at refresh.

Douglas R. Colkitt authored the parity-side obstruction, repair and original binary phase-frame checkers. Prepared by Wentao Li (VictorLiwentao, @Is__Victor) with substantial AI assistance, under Apache-2.0.

Memoize basis on row tuples and reduce contains against one basis so the
historical parity-side audit keeps identical h=8/10/26 receipts while the
three binding certificates change only the binary_phase_frames.py pin.
Five alternating fresh-process pairs on CPython 3.12.3 / Linux give median
27.349 → 13.463 seconds with fieldwise-identical h=8/10/26 receipts.
@Mister-Meeseeks

Copy link
Copy Markdown
Contributor

Review found a cache-dependent validation regression in binary_phase_frames.basis at head 54d7f5fd4ef6073b6399d1e6e73773f61fe4360a:

_basis_cached.cache_clear()
basis((1,))       # warms the cache
basis((1.0,))     # now returns (1,), bypassing the integer assertion

The baseline rejects (1.0,), and your optimized implementation also rejects it with an empty cache. Validation inside the memoized function is skipped because these tuple keys compare equal. Please validate row types before lookup (or preserve element types in the key), add a warm-cache regression control, and refresh the affected source pins. Integer-input receipt equivalence remains useful; this hold concerns preserving verifier rejection behavior.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants