Skip to content

Prove the sharp query-price threshold for the #5554 path reduction (no new κ) - #5936

Open
petalas wants to merge 1 commit into
CrocSwap:mainfrom
petalas:research/w12-1022ac-path-query-price
Open

petalas wants to merge 1 commit into
CrocSwap:mainfrom
petalas:research/w12-1022ac-path-query-price

Conversation

@petalas

@petalas petalas commented Oct 27, 2026 •

Copy link
Copy Markdown
Contributor

Result (scoped proof, no new κ)

zxv's #5554 (research/kappa-architecture-frontier) reduces every FULL/QUERY mask of the rank-b productive-helper path to one canonical invoice per FULL count, assuming each QUERY costs v rank-one jobs. Its Open next question 3 asks about a changed query law. This package changes only the query price to w*v and proves, with t=1-C:

  • For 1 <= w <= w* = b^t + (2b+1)^t - (3b)^t, the canonical reduction holds at every n, for all pair counts, splits and masks. The minimum is C_n + (w-1) v |n-3|. Convexity, the three-sign exclusion and the price frontier/ratio gate transfer with c_n -> c_n + (w-1)|n-3|.
  • For w > w*, merging the two outer 10 pairs into one 11 pair beats the canonical invoice at every n >= 6, by 2v(w-w*). Research: the productive-helper path (#4440 lineage) can't pass κ ≈ .00304 without cheaper helpers #5554's cap must not be transferred.
  • For w < 1, the family is unbounded below at every n.

At b=8 and C=.0034, w* = 1.03859829952. A per-query surcharge above about .0386 rank-one units per port breaks the canonical form.

The proof reuses #5554's moves, sorted by their effect on the query count. Moves that delete queries only improve when w >= 1. Moves that keep the count are unchanged. The 11-split adds two queries and costs w - g_k, with g_k increasing. A new move handles the k=0 case: end bit 0 plus pair 11 becomes end bit 1 plus pair 10, which is strictly favorable by subadditivity.

Evidence and reproduction

~/git/integer-mult-bounds/.venv/bin/python3.12 -B research/path-query-price-threshold/verify.py
# PASS_PATH_QUERY_PRICE_THRESHOLD masks_p_le=6 block_ranks=2 exponents=4 checks=456  (~7 s)
~/git/integer-mult-bounds/.venv/bin/python3.12 -B scripts/research_package.py --package research/path-query-price-threshold
~/git/integer-mult-bounds/.venv/bin/python3.12 -B scripts/check_research_commit.py --package research/path-query-price-threshold --check-source-history

All three pass locally on CPython 3.12. The verifier evaluates the literal equation (1) with query price w on every mask with p <= 6 and every split. It uses b in {2,8}, t in {1/2, 9/10, 4983/5000, 999/1000} and 60-digit decimals. It checks that the canonical invoice is minimal below w*, the merge identity and gap above w*, monotonicity of g_k, and the 00-pair gain below w=1. It pins the bytes of #5554's PROOF.md.

Limitations

Open next questions

  1. Which masks are optimal for w > w*, once 11 side pairs survive?
  2. Does the reduction survive a rank-q query that also earns a rank-q target?
  3. Does a surcharge below w*-1 move Research: the productive-helper path (#4440 lineage) can't pass κ ≈ .00304 without cheaper helpers #5554's optimal FULL count, 16 for the Improve complete conditional κ to 0.00304153 via coupled P104 contacts #5551 bill at C=.0034?

Related open work

Credit

The path family, equation (1), the canonical reduction and the price frontier come from zxv's #5554, which builds on Ali Romman's #5405/#5409 and the predecessors credited there. The query-price parameter, threshold, k=0 move, sharpness witness and unboundedness result are new here.

CI notes

All checks passed on head 6bc26ee287c074011576f067d19c1e97ef1344ff: plan and replay (research/path-query-price-threshold), run https://github.com/CrocSwap/integer-mult-bounds/actions/runs/40524001602.

…path reduction

Charge each QUERY stage w*v. The canonical one-invoice-per-FULL-count
reduction and its price frontier transfer exactly for
1 <= w <= b^t+(2b+1)^t-(3b)^t; above that a merged 11 pair beats the
canonical invoice at every n >= 6, and below w=1 the family is unbounded.
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.

1 participant