Repository navigation
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Exact integer Taylor evaluation reduces the complete frozen PR4440 caller's local median wall time by 37.88%, from 7.509418 s to 4.665133 s, with identical complete scientific results and exact exponential endpoints. Claim type: scoped implementation-equivalence proof, finite conformance and a complete-command performance measurement. No new kappa.
This contribution was produced by Nick Petalas. Credit ywz65's PR2552 for the integer Taylor method and explicit question about other retained interval engines. Cinna Davis's PR4440 and the retained zxv, Jacob Alan Sussman, native, BIT, compiler and outer lineage supply the scientific caller. Integer arithmetic and Horner evaluation are standard. The new step is the exact fixed-loop/remainder implementation and source-specific complete-command improvement. Frozen sources and credit lines retain their bytes.
Evidence
Five alternating fresh-process pairs on CPython 3.12.15, macOS 27.0.1 arm64, with concurrent work on an 18-logical-CPU host:
The written endpoint proof preserves the source's terms j=0 through 48 and
F/(1-x/50)remainder exactly. Its earlier integer-Taylor predecessor uses a different stopping rule, dyadic output rounding and another remainder; those contracts are not silently transferred.Local checks pass:
PASS_REGISTERED_RESEARCH_PACKAGE.Scientific implementation commit:
83e5af122c3eef1e4c21d4a84b16b7b7cb923e23. Head541729c38176ed96359d88ac99fb1587a7db795aonly clarifies metadata wording about exact rational output without dyadic rounding. Source bindings use canonical main7c49fe32c55de02c2c873655c804b16e4c3fef0a, priority revision 8, refreshed before publication.Reproduce from the repository root, using the actual local interpreter path:
Another CPython 3.12 executable may replace that path. Standard library only. Generated receipts and benchmark reports go to stdout; redirect them outside the checkout. The package README records all raw timing samples, hashes, environment, proof and limits.
Limitations and unrun obligations
The implementation domain is exact int/Fraction x with 0<=x<1 and numerator/denominator bit lengths at most 16,384. The adapter is local to a fresh process. The performance result covers this exact caller and host; no universal speed guarantee or automatic production migration is claimed. Managed Python allocation is a documented bounded-runtime deviation.
This is implementation work, not a new scientific audit or admission of PR4440. No native all-width theorem, physical multiplier, selected cold replay, Lean, Docker or full supplier admission was run. The selected frontier and five framework assumptions remain. Independent human and formal proof-kernel review are unclaimed. No registered check was deferred solely to CI.
Open next questions
Can a source-specific integer evaluation help another exact moment engine with a different polynomial or remainder? First pin that engine, derive its exact endpoints and time its unchanged complete caller. No further optimization or migration is reserved.
Related open work
No open submission for this exact exponential engine or complete PR4440 runtime workload appeared in the live engine/caller searches. Adjacent caller and compiler work has separate contracts and quantities:
The completion refresh inspected all 15 account PRs still open and created since the advance CLAIM at 2026-11-02T19:33:12Z, including this PR. The other 14 are #6381 through #6394. None studies this exact fixed-step exponential, its exact endpoint trace or the complete PR4440 runtime measurement. The related distinctions above remain. No disagreement on a common computed quantity was identified, and no extra computation checked another contribution's numbers. Main, merged keyword, live claim and local reservation checks supplement the body searches; unpublished work and arbitrary historical diffs remain outside coverage.
CI notes
Both hosted checks passed at exact head
541729c38176ed96359d88ac99fb1587a7db795ain Registered research packages run 41514316445. The completed check list was read once withgh pr checks 6395 --repo CrocSwap/integer-mult-bounds: plan passed in 3m41s, and replay (research/query-controller-integer-taylor) passed in 3m38s. Separate run metadata confirms statuscompleted, conclusionsuccessand the matching head.Hosted success covers execution of the registered normal/optimized finite replay and its metadata/source checks. It does not establish the local timing percentage, independent scientific acceptance or a formal-kernel theorem. Every listed registered, committed/source-history and export check also passed locally. No CI failure remains.
Merge Danger
Door: two-way. Blast radius: isolated.
Only nine files in a new opt-in research package are added. Shared code, frozen evidence and selected-frontier files are unchanged.