Astrophysics Pulsar Timing3 From Jcost

A template, not a result

Pulsar timing is the practice of predicting when a pulsar's radio pulses should arrive, then measuring the small deviations, called residuals, between prediction and observation. Millisecond pulsars are astonishingly regular clocks, with residuals around 100 nanoseconds. The module named Pulsar_Timing3_FromJCost was meant to connect these residuals to a cost function from Recognition Science, but the file itself documents that this connection is a research note, not an established result.

The file defines a quantity called domainCost as J(m/e), where J is a specific cost function from the Recognition Science framework and m and e are real numbers. The Lean code proves three general facts about this definition: it equals zero when m equals e, it is never negative when m and e are positive, and a certain threshold value phi minus 3/2 is positive. Each of these is a theorem about the abstract cost function, not about pulsars. The file's own docstring states this plainly: it proves nothing specific to pulsar timing, because the definition of domainCost makes no reference to any pulsar property.

The intended application appears in the docstring's research note. It sketches that timing noise might scale as J(phi) times the spin period, which for a 1 millisecond pulsar would give a residual of about 118 microseconds, or 118,000 nanoseconds. The measured residuals for such pulsars are around 100 nanoseconds, so the estimate is off by a factor of about 1000. The note calls this discrepancy structural, meaning the proposed scaling does not match observation.

What the module genuinely establishes is a template. The same three generic theorems are shared verbatim across 2383 sibling modules, all derived from a single universal statement in the framework's library. To turn this template into a theorem about pulsar timing, one would need a definition of m and e in terms of pulsar properties, such as spin period or timing noise. That definition does not exist in this file. The module is a certified shell waiting for physical content, and the physical content it sketches fails its own numerical test.

theorem domainCost_at_eq (r : ℝ) (h : r ≠ 0) : domainCost r r = 0 := by
  unfold domainCost; rw [div_self h]; exact Jcost_unit0

theorem domainCost_nonneg (m e : ℝ) (hm : 0 < m) (he : 0 < e) : 0 ≤ domainCost m e := by
  unfold domainCost; exact Jcost_nonneg (div_pos hm he)

theorem canonicalThreshold_pos : 0 < canonicalThreshold := by
  unfold canonicalThreshold; linarith [phi_gt_onePointFive]

def domainCost (m e : ℝ) : ℝ := Jcost (m / e)

def canonicalThreshold : ℝ := phi - 3 / 2

What this page does not claim

The module does not prove any statement about actual pulsar timing behavior. The proposed residual scaling is not a measured or derived result; it is a research note that fails its own numerical check. The three theorems do not depend on any pulsar-specific definition and apply equally to any positive real numbers m and e.

Verify this page

Every tagged claim above names its theorem. To check one yourself rather than trust this page, elaborate the source module with Lean 4 and audit its axiom basis:

$ lake env lean IndisputableMonolith/Astrophysics/Pulsar_Timing3_FromJCost.lean
expected axiom basis: [propext, Classical.choice, Quot.sound] (the Lean kernel's standard three; no RS-specific axioms)

A page whose claims cannot be reproduced this way does not ship. In production, every anchor links to the exact declaration in the public source release, and this block carries the build receipt for the page itself.

Derived articles

This page is generated by a question-recursion engine: the questions its answers raise become the next pages. The current agenda, with open targets marked red: