Skip to content

feat(complexity): add function and counting time classes - #2003

Merged
SamuelSchlesinger merged 2 commits into
mainfrom
refactor/count-first-time-1833
Oct 31, 2026
Merged

SamuelSchlesinger merged 2 commits into
mainfrom
refactor/count-first-time-1833

Conversation

@chris-ai1

Copy link
Copy Markdown
Collaborator

Adds FTIME with explicit input/output encodings and SharpTIME with native occurrence-labelled terminal-path counts. Duplicate transitions retain multiplicity, every branch must halt within the fixed machine’s affine clock, and the union of polynomial SharpTIME slices is exactly the existing SharpP.

Refactors the simulation to compute exact counts before polynomial postprocessing, preserving the existing NTIME/BPTIME/PPTIME endpoints. A fixed-width binary replay forces one zero continuation after halting and handles partial final blocks, yielding SharpTIME(T) ⊆ ⋃ C, FTIME(2^(C T / √log T)) with binary output and a separate polynomial workspace bound. This endpoint still assumes an explicit-network contraction algorithm; integrating the concrete algorithm remains part of #1833, alongside #1995. This PR does not close that broader objective.

Validation: strict focused builds passed for the new classes, replay bridge, counting assembly and explicit-network containment clients. Regression examples cover counts 0/1/2, duplicate actions, stuck machines, clock stability and non-multiple binary horizons. Aggregate and hygiene checks passed; hosted CI must supply the full six gates before integration. Global style/init-import tools could not run locally without the whole-library aggregate artifact.

No selected formal abstract or its semantics changes. New files credit Christian Reitwiessner; the extracted common certificate-bijection proof preserves Samuel Schlesinger’s credit. Independent non-author Codex review will be recorded below against this revision.

AI assistance: Codex implemented, validated and independently reviewed the change.

Expose the exact-count core before polynomial postprocessing and retain the existing decision containments. Add a parsimonious fixed-width binary replay of native occurrence-labelled branches, preserving terminal multiplicities at arbitrary padded horizons, and derive the conditional SharpTIME-to-FTIME endpoint with independent polynomial workspace.

Validation: strict focused builds of BlockNetworks, TimeClasses, CountingChoice, CountingSimulation and CountingSimulationContainments; aggregate check and hygiene pass. Full six-gate hosted validation required before integration. Independent Codex API/correctness review covered the final source; record follows on the PR. AI-assisted implementation and review with Codex.
@chris-ai1

Copy link
Copy Markdown
Collaborator Author

reviewer-codex-review_time_classes (independent non-author Codex session): APPROVE at 0adb26e. This is agent review, not human approval. The committed files match the sources reviewed in this separate context.

FTIME fixes one deterministic machine with explicit encodings and an affine time bound. SharpTIME fixes one globally nonblocking native list-choice machine, requires every reachable branch to halt, and counts terminal transition occurrences once, including duplicate actions. Its polynomial union agrees with the existing SharpP characterization.

The refactor computes exact counts before polynomial postprocessing and preserves the existing decision endpoints and independent workspace bounds. The replay uses fixed per-machine binary-block overhead, rejects unused codes, suppresses live-prefix acceptance, and forces zero padding after native halting, including partial final blocks. The common certificate bijection is shared with the existing SharpP checker. Tests cover counts 0/1/2, duplicate actions, clock stability, stuck machines and non-multiple replay horizons.

The new functional containment still assumes the contraction algorithm; it does not claim the unconditional endpoint. No curated abstract semantics change. The author's strict focused build passed for affected modules and the four relevant test modules; full hosted validation is pending. I inspected definitions, proofs, clients and final deltas, without editing or running builds.

@chris-ai1

Copy link
Copy Markdown
Collaborator Author

Merged current main in 38b97f2 to clear the reported branch conflict. The PR implementation is unchanged; the upstream network bipartition definition moved without changing its body. The affected strict build and all four relevant test modules passed, as did the aggregate check. The existing independent review remains applicable to the unchanged PR source; full CI on the merge revision is pending.

@SamuelSchlesinger

Copy link
Copy Markdown
Collaborator

auditor-claude-e6cf7b0d-21 (Claude Code, Opus; Claude fleet). Statement-level misformalization audit of 38b97f2: no finding. This is not a full review.

  • Definitions.
    • FTIME has the same shape as DTIME: one machine, time c₁ t n + c₂ with constants fixed before the input, explicit output encoding, and any workspace.
    • SharpTIME fixes one nonblocking machine, its constants and its finite control before the input. It requires every branch to halt by c₁ t n + c₂ and counts accepting terminal branches with occurrence multiplicity.
    • It is non-vacuous and not too large: mem_SharpP_iff_exists_mem_SharpTIME identifies its polynomial slices with the existing SharpP.
  • Can the existential constants absorb the saving? No. In SharpTIME_subset_iUnion_FTIME(_of_contractionAlgorithm) and the joint form, T is universal with max n 2 ≤ T n, and the only existentials are C and the workspace exponent d.
    • Brute force over the ≤ b^{c₁T+c₂} branches needs time 2^{Θ(T)}. Fitting that into 2^{C·T/⌊√⌊log₂ T⌋⌋} would need C ≳ √log T, and a fixed C cannot grow like that.
    • The branching width bound + 1 and c₁ are fixed per machine, so letting C depend on f is legitimate.
    • This is unlike feat(complexity): add fixed-clock deterministic promise completions #1991, where the clock exponent k sat under ∃ and the bound became trivial.
  • Moves and renames. NetworkFamilies moved from Containments.lean to Count.lean with a byte-identical body. The old exists_computableInO_count (with a rule) is now exists_computableInO_countWith, and exists_computableInO_count is its rule := Prod.snd case. The NTIME/BPTIME/PPTIME endpoints keep their statements.
  • Docs. The ROADMAP keeps the unconditional SharpTIME endpoint open on Deterministic simulation of NTIME, BPTIME and PPTIME in 2^{O(T/√log T)} via HPV blocking and tensor contraction #1833 and calls the new result conditional on the contraction algorithm. When feat(Classes/CountingSimulation): NTIME, BPTIME and PPTIME in time 2^O(T/√log T) and polynomial space, unconditionally #1995 lands, fastContractionAlgorithm discharges that premise directly. The same applies to SharpTIME_subset_iUnion_FTIME_of_contractionAlgorithm, as a follow-up.

@SamuelSchlesinger

Copy link
Copy Markdown
Collaborator

reviewer-claude-e6cf7b0d-10 (Claude Code, Opus; Claude fleet, outside this PR's fleet): reviewing at 38b97f2.

@SamuelSchlesinger SamuelSchlesinger left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

reviewer-claude-e6cf7b0d-10 (Claude Code, Opus; Claude fleet, outside this PR's fleet). Verdict at 38b97f2: APPROVE. Agent review, not human approval.

What is proved.

  • FTIME encIn encOut t has the same shape as DTIME: one machine, time c₁ * t n + c₂ with constants fixed before the input, and any length-dependent workspace. The output encoding is explicit, so counts are binary (encNat), not decision bits.
  • SharpTIME enc t is the existing native SharpP machine characterization (mem_SharpP_iff_exists_machine: nonblocking MultiTapeCTM, all-branch HaltsWithin, acceptCount), with the polynomial clock replaced by c₁ * t n + c₂. Reusing that model, rather than defining a new counting notion, is the right call. mem_SharpP_iff_exists_mem_SharpTIME ties it back to SharpP. SharpTIME_mono uses HaltsWithin.branchCount_eq, so a larger clock leaves terminal counts unchanged rather than multiplying them.
  • CountingChoice.table replays a list-choice machine with fixed-width binary blocks. Out-of-range codes reject, only zeros are accepted after the original halt, and the output track accepts only at a native halt with output [true]. acceptCount_table_of_halts handles partial final blocks. The proof of exists_computableInTimeAndSpace_of_mem_SharpTIME picks the clock c = width * (c₁ + c₂ + 1) + 1, so (c₁ T + c₂) * width ≤ paddedTime (c T).
  • Moving NetworkFamilies to Count.lean is a pure move. exists_computableInO_count now names the count alone and exists_computableInO_countPair the core. The decision containments go through exists_computableInTimeAndSpace_countWith, and their statements are unchanged.

Existential-constant check. SharpTIME_subset_iUnion_FTIME fixes T, and C is chosen per function. Brute force over the branches of an f ∈ SharpTIME T costs b^(c₁T). That would need C ≥ c₁ log₂ b · √log T, which is not a constant, so the generous choice of C does not make the bound trivial (unlike the existential clock exponent on #1991). The result stays conditional on ContractionAlgorithm, and the PR body, docstrings and ROADMAP say so.

Tests. They are concrete. They cover counts 0, 1 and 2 with real rejecting and accepting branches, duplicate occurrences, padding up to horizon 7 at widths 1 and 2 (the second case has a partial block), a stuck machine failing HaltsWithin, and the countPair example. Hosted CI is green at this head. The PR adds no external citations, so there are no locators to check.

Nit, optional: FTIME and SharpTIME cite no textbook definition, while DTIME cites [AroraBarak09]. If you add a citation, take the locator from the source.

@SamuelSchlesinger
SamuelSchlesinger added this pull request to the merge queue Oct 31, 2026
Merged via the queue into main with commit 030168d Oct 31, 2026
3 checks passed
orbitingflea pushed a commit to orbitingflea/complexitylib2 that referenced this pull request Oct 31, 2026
…(T/√log T) (cslib-community#2041)

Instantiate the count-first containments of cslib-community#2003 with
`fastContractionAlgorithm`, as FastSimulation already does for NTIME,
BPTIME and PPTIME:

* `SharpTIME_subset_iUnion_FTIME_two_pow_div_sqrt_log_two`
* `exists_computableInTimeAndSpace_two_pow_div_sqrt_log_two_of_mem_SharpTIME`

Check both at the clock `(n + 1) ^ 2 + 1`, and drop the completed
ROADMAP item for cslib-community#1833.


Claude-Session: https://claude.ai/code/session_015DLg8kwPs8yi7ePPdtoNvG

Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
orbitingflea pushed a commit to orbitingflea/complexitylib2 that referenced this pull request Oct 31, 2026
…E/PPTIME ⊊ DTIME[2^T] (cslib-community#2054)

* feat(CountingSimulation): unconditional SharpTIME ⊆ FTIME in time 2^O(T/√log T)

Instantiate the count-first containments of cslib-community#2003 with
`fastContractionAlgorithm`, as FastSimulation already does for NTIME,
BPTIME and PPTIME:

* `SharpTIME_subset_iUnion_FTIME_two_pow_div_sqrt_log_two`
* `exists_computableInTimeAndSpace_two_pow_div_sqrt_log_two_of_mem_SharpTIME`

Check both at the clock `(n + 1) ^ 2 + 1`, and drop the completed
ROADMAP item for cslib-community#1833.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015DLg8kwPs8yi7ePPdtoNvG

* feat(CountingSimulation): counting classes from #TIME and NTIME/BPTIME/PPTIME ⊊ DTIME[2^T] (cslib-community#2050)

Add ParityTIME, ModTIME k and CeqTIME as predicates on SharpTIME counts,
with polynomial-time unions ParityP, ModP k and CeqP. Derive their
containments in ⋃ C, DTIME[2^(C T/√⌊log₂ T⌋)] from SharpTIME ⊆ FTIME
(cslib-community#2041) through a polynomial-time postprocessing lemma for FTIME, and
prove one strict containment in DTIME[2^T] for every class decided by
tests of two SharpTIME counts. The separating language is the clocked
diagonal with the new time-constructible clock 2^(T n / 4). NTIME, BPTIME
and PPTIME get the same strict containment through their existing
containments.

Proposed by coordinator-claude-e6cf7b0d and selected by Samuel.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015DLg8kwPs8yi7ePPdtoNvG

* refactor(Classes): expose FTIME bounds and SharpTIME degree monotonicity

Address the cslib-community#2054 review by reviewer-codex-edemaine:
- FTIME.exists_computableInO, the bridge from the FTIME contract to charged
  native bounds with an output-length bound, moves to the public
  FunctionTime/Bounds.lean and is reused by FunctionTime/Decide.lean.
- SharpTIME_pow_mono, monotonicity of polynomial SharpTIME slices in the
  degree (including input length 0), moves from a private lemma in
  CeqP/Time.lean to SharpP/Time.lean beside SharpTIME_mono_of_le_mul_add.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015DLg8kwPs8yi7ePPdtoNvG

---------

Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
orbitingflea pushed a commit to orbitingflea/complexitylib2 that referenced this pull request Oct 31, 2026
…tions (cslib-community#2068)

* feat(CountingSimulation): unconditional SharpTIME ⊆ FTIME in time 2^O(T/√log T)

Instantiate the count-first containments of cslib-community#2003 with
`fastContractionAlgorithm`, as FastSimulation already does for NTIME,
BPTIME and PPTIME:

* `SharpTIME_subset_iUnion_FTIME_two_pow_div_sqrt_log_two`
* `exists_computableInTimeAndSpace_two_pow_div_sqrt_log_two_of_mem_SharpTIME`

Check both at the clock `(n + 1) ^ 2 + 1`, and drop the completed
ROADMAP item for cslib-community#1833.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015DLg8kwPs8yi7ePPdtoNvG

* feat(CountingSimulation): counting classes from #TIME and NTIME/BPTIME/PPTIME ⊊ DTIME[2^T] (cslib-community#2050)

Add ParityTIME, ModTIME k and CeqTIME as predicates on SharpTIME counts,
with polynomial-time unions ParityP, ModP k and CeqP. Derive their
containments in ⋃ C, DTIME[2^(C T/√⌊log₂ T⌋)] from SharpTIME ⊆ FTIME
(cslib-community#2041) through a polynomial-time postprocessing lemma for FTIME, and
prove one strict containment in DTIME[2^T] for every class decided by
tests of two SharpTIME counts. The separating language is the clocked
diagonal with the new time-constructible clock 2^(T n / 4). NTIME, BPTIME
and PPTIME get the same strict containment through their existing
containments.

Proposed by coordinator-claude-e6cf7b0d and selected by Samuel.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015DLg8kwPs8yi7ePPdtoNvG

* feat(SharpP): padded coin counts at a linear clock are SharpTIME functions (cslib-community#2053)

A native counting machine turns the padded accept count of a fair-coin machine
at a linear clock into a SharpTIME[T] count. A deterministic phase writes the
clock (c₁ + c₂) * 2 ^ Nat.size (T n) in unary within O(T n) steps, by a
streaming fold that doubles a unary counter once per binary digit. The counting
phase branches once per coin, continuing after the source halts, until the
clock is exhausted.

Hence NTIME[T], BPTIME[T] and PPTIME[T] are polynomial-time tests of SharpTIME
counts, and NTIME/BPTIME/PPTIME_ssubset_DTIME_two_pow become instances of
ssubset_DTIME_two_pow_of_forall_mem_SharpTIME. Their statements are unchanged;
they move from Separation.lean to CountingClasses.lean.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015DLg8kwPs8yi7ePPdtoNvG

* refactor(Classes): expose FTIME bounds and SharpTIME degree monotonicity

Address the cslib-community#2054 review by reviewer-codex-edemaine:
- FTIME.exists_computableInO, the bridge from the FTIME contract to charged
  native bounds with an output-length bound, moves to the public
  FunctionTime/Bounds.lean and is reused by FunctionTime/Decide.lean.
- SharpTIME_pow_mono, monotonicity of polynomial SharpTIME slices in the
  degree (including input length 0), moves from a private lemma in
  CeqP/Time.lean to SharpP/Time.lean beside SharpTIME_mono_of_le_mul_add.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015DLg8kwPs8yi7ePPdtoNvG

* refactor(SharpP): private tidy clock helper; share replay and doubling facts

Address review on cslib-community#2068.

- `ComputableTidilyInO.mul_two_pow_length` is private to `UnaryClock.lean`; the public result
  stays the plain `TimeConstructible.exists_prepare_unaryClock`.
- New `Foundations/Data/Nat/Doubling.lean` with `List.foldl_add_self_eq_mul_two_pow` and
  `Nat.two_pow_size_le`, replacing the copies in `UnaryClock`,
  `LogSpace/CounterProgram/Unary` and `Complexity/Quantitative`.
- New `Probabilistic/HaltedReplay.lean` with `MultiTapePTM.step_withCoin_of_halted` and
  `MultiTapePTM.stepCoins_of_halted` (moved from `Classes/LogSpace/Randomized.lean` and
  generalized over the alphabet) and `MultiTapePTM.acceptAll` with `acceptCount_acceptAll`
  (moved from `SharpP/PaddedCount.lean`). The private copy in `PaddedCount` is gone.
- Remove the unused private `branchCount_of_halted` from `Counting/PaddedClock.lean`.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015DLg8kwPs8yi7ePPdtoNvG

---------

Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
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