Skip to content

refactor(primes): explicit MAX_RULES_PER_PARTITION cap + documented bounds - #53

Open
discreteds wants to merge 1 commit into
developfrom
bugfix/prime-table-explicit-cap
Open

refactor(primes): explicit MAX_RULES_PER_PARTITION cap + documented bounds#53
discreteds wants to merge 1 commit into
developfrom
bugfix/prime-table-explicit-cap

Conversation

@discreteds

Copy link
Copy Markdown
Member

Explicit prime-table cap + documented bounds

Replaces the opaque _sieve(3572) (which silently meant "the first 500 primes")
with an auditable, named limit.

What changed

  • MAX_RULES_PER_PARTITION = 10_000 — a named constant is now the table size / max rules per partition (was an arbitrary, undocumented 500 encoded as the sieve limit 3572).
  • _first_n_primes(n) — sizes the sieve by prime count (Rosser bound p_n < n(ln n + ln ln n)), so the cap is expressed in the dimension that matters (rules), not a magnitude.
  • get_prime over-index error now names MAX_RULES_PER_PARTITION and points at the CONTEXT_KEY remediation.
  • Module docstring documents the two independent bounds, which were previously conflated/undocumented:
    • Combination width ≈ 15 — intrinsic to int64 (primorial of first 15 primes < 2⁶³, 16th overflows); enforced by checked_multiply / LatticeWidthExceededError.
    • Rules per partition = table size — each rule needs a distinct prime; enforced by get_prime.

Why not a precomputed literal / data file

The sieve runs once at import in microseconds — a literal list or a file buys no speed and adds packaging/IO surface. A table "up to 2⁶⁴" is impossible (~4.2×10¹⁷ primes ≈ exabytes) and the wrong dimension anyway: primes are indexed by rule position, never by magnitude.

Testing

  • tests/accumulator/test_primes.py: table-size-equals-cap invariant, _first_n_primes (empty/small/exact-count/boundary 10000th=104729), over-cap get_prime error names the constant. 19 passed.
  • Full accumulator suite 203 passed / 0 failed; backend purity 15 passed; ruff clean.

🤖 Generated with Claude Code

…two bounds

Replace the opaque _sieve(3572) magic (which silently meant '500 primes') with a
named MAX_RULES_PER_PARTITION constant (raised to 10_000) and a _first_n_primes(n)
helper that sizes the sieve by prime count via the Rosser bound. The table is
still computed at import (an instant bounded sieve) — a precomputed literal/file
buys nothing, and a table 'up to 2**64' is impossible and the wrong dimension
(we index by rule count, not prime magnitude).

Document the two independent limits: the intrinsic width-15 combination bound
(primorial <= int64, enforced by checked_multiply) vs the rules-per-partition
table-size cap (enforced by get_prime).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
@sonarqubecloud

Copy link
Copy Markdown

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