Skip to content

mod-arxiv-2505-14698.md

Latest commit

 

History

History
61 lines (39 loc) · 5.9 KB

mod-arxiv-2505-14698.md

File metadata and controls

61 lines (39 loc) · 5.9 KB
Raw

Module hook: arXiv 2505.14698 (hypercomputing supertasks and Church–Turing)

URL: https://arxiv.org/pdf/2505.14698

Bibliographic note: Vincent C. Müller, On the Possibilities of Hypercomputing Supertasks (arXiv:2505.14698v1, cs.LO, May 2025). Argues against using digital hypercomputing as a reason to reject or re-interpret the Church–Turing thesis in a strong form: critiques common targets as a straw man (“maximality thesis”), then examines Zeno-style machines (supertasks—infinitely many computational steps in finite time). Main logical move: effective Zeno-machine specifications face a dilemma—either they lack well-defined output states, or they are specified with outputs but land in contradiction. Non-effective repairs or ad hoc rules for semi-decidable cases are considered but not vindicated. Conclusion (philosophical): hypercomputing supertasks are not realized in the actual world, so they do not force abandonment of the traditional Church–Turing reading. Not a sequential-decision, RL, or AIXI construction paper.

Role in AIXI stack

  • Families A / B / C: None as an algorithmic ingredient. This is a logic / philosophy of computation paper about hypercomputation and supertasks, not a percept model, planner, or mixture law.
  • Where it belongs in the plan: Same bucket as other theory lenses in IMPLEMENTATION_PLAN.md §0 and supplementary modules—scope boundaries, reviewer-facing language, and why the repo stays with finite, Turing-bounded runtimes. It supports the posture that we do not rely on Zeno clocks, supertask completion, or “digital hypercomputer” output oracles.
  • Pairing: Strong overlap with mod-cs-0412022.md (Potgieter on Zeno machines and hypercomputation) and mod-arxiv-1411-5679.md (Kim on infinite-time / Zeno idealizations and halting). Use Müller when the question is whether supertask or Zeno-machine stories justify stronger-than-Turing agents in product—this paper’s line is that effective supertask specs are problematic, reinforcing cite-only, non-hypercomputational boundaries.
  • Plan anchors & boundary rollup: IMPLEMENTATION_PLAN.md §1.1 and §8; SUPERTASK_BOUNDARY.md.

Formal objects to carry into code

Object (paper) Use in repo
Digital hypercomputing (as challenge to Church–Turing) Non-scope: no implementation path assumes physically realized hypercomputation.
Zeno machine / supertask (infinite steps in finite time) Non-scope: no Zeno scheduling, no “completed supertask” API.
Dilemma: no output states vs. contradictory output-bearing specs Documentation lens only: motivates clear I/O semantics and finite-step execution traces in runtime design—not a new formal type in code.
“Maximality thesis” vs. traditional Church–Turing Assumptions / comms only: optional nuance when writing computability footnotes; no change to §1 symbols.

No new symbols for §1 notation ledger unless a shared ComputabilityAssumption doc type is introduced later; not required for v1.

Proposed API / data structures

  • None required. Optional future doc-only statement: runtime assumes standard Turing computability with explicit time / step budgets; no reliance on supertask completion or hypercomputer output.
  • Testing: No new hooks; tests remain finite-state / finite-budget.

Implement vs cite-only

  • Cite-only for implementation. Link from IMPLEMENTATION_PLAN.md §8 / supplementary modules when discussing Church–Turing, hypercomputation rhetoric, and supertasks.
  • Do not implement Zeno timing, supertask semantics, or hypercomputing oracles in Families A–C.

Dependencies on other aixi/ modules

  • mod-cs-0412022.md: Same cluster (Zeno machines, hypercomputation, Church–Turing); cross-link when both are cited.
  • mod-arxiv-1411-5679.md: Complementary impossibility / boundary arguments around infinite-time and Zeno-style idealizations.
  • mod-hilbert-machine.md: Adjacent “limits of formalization / computability narrative”; optional cross-link.
  • IMPLEMENTATION_PLAN.md §1.1, §0, §8 and SUPERTASK_BOUNDARY.md: Primary consumers of this hook’s intent.

Validation notes (Math & CS Wizard)

Bibliographic check (blocking)

  • Actual paper: arXiv 2505.14698 is Müller (2025 on arXiv), cs.LO—philosophy / logic in CS on hypercomputing supertasks and Church–Turing, not MC-AIXI, Self-AIXI, or AIQI algorithms. Any prior table row implying an “algorithmic bridge” to those variants should be revised in the plan to match this cite-only boundary role.
  • Distinct from algorithmic AIXI approximator papers: no new loss, prior, or planning API falls out of this reference.

Notation vs §1 (notation ledger)

  • No clash with §1 symbols ((\mathcal{A},\mathcal{O},\mathcal{R}), (\xi), etc.). No ledger update required from Müller alone.

Computability & implementation scope

  • Cite-only: executable agents remain finite, Turing-computable update rules with explicit budgets; supertasks and digital hypercomputers are out of scope for runtime design.
  • Consistent with §8: universal exact Bayes / full Solomonoff remains incomputable; this paper adds a supertask / hypercomputation rhetoric guardrail, not a new approximator.

Consistency with module body (this file)

  • Role / formal objects / API / cite-only / dependencies align with treating Müller as a theory lens alongside Potgieter, Kim, and the plan’s finiteness assumptions.
  • Sign-off: Wizard accepts the module spec for downstream milestones; optional doc invariant—runtime and public docs must not claim supertask-completed computation or physically realized digital hypercomputing as part of the stack.