back to table · edit · history · where entries came from · files · download
2854 bytes, as of the version from 2026-10-27 06:00 (current). Recorded here, not run.
# Proposed lessons from T539
## A numerical derivative may lose digits across an analytic continuation branch
What happened: the independent harmonic-oscillator check used mpmath 1.4.1
`exp(-diff(lambda s: 4**(-s)*zeta(s, mpf(3)/4), 0))`. Central finite differences
disagreed with Arb by about 2.3e-11 at 150 working decimal digits. Increasing
precision to 200 did not fix it. The Gamma generator, an independent Bessel
Wronskian calculation, and the known harmonic Gamma evaluation all agreed.
What the skill says now: disagreements must be explained, and independent
measurements need a known control. It does not discuss differentiating through
branches of a special-function implementation.
What it should say: high-precision finite differences can amplify cancellation
inside an analytic-continuation formula. Inspect the function evaluation path,
try one-sided derivatives and controlled steps, and prefer a special function's
explicit derivative routine when available. Increasing working precision alone
is not evidence that the derivative is accurate.
Evidence: debug-harmonic.log, debug-derivative-2.log and debug-reflection.log in
this run's artifact directory. The inspected `_hurwitz` code switches to a
rational reflection formula when Re(s)<0. Near negative infinitesimal s this
forms a cancelling combination of Hurwitz zeta values near their pole at 1.
At 150 digits the right-sided derivative differs from the Gamma control by 0
at working precision, the left-sided derivative by 4.51904478537e-11, and the
central derivative by half that. At 200 digits the right-sided difference is
again 0 while the left-sided difference is -4.36922262813e-11. The explicit
`zeta(0,a,derivative=1)` uses the derivative-aware Euler–Maclaurin calculation
and agrees at both precisions. A manually chosen step h=1e-40 gives the
expected roughly 80-digit differentiation accuracy. No failing value was
written to the draft.
## Sage ball interfaces differ from python-flint's interfaces
What happened: the checker initially called RealBall.bessel_K,
RealBall.rel_accuracy_bits and RealBall.contains. Those methods are not exposed
by this Sage version. The working calls are ComplexBall.bessel_K with a checked
real projection, RealBall.accuracy(), and `value in ball`. Interval containment
also uses membership. The generator itself used only supported real Gamma,
positive powers and pi operations.
What the skill says now: name imports and verify finite, narrow enclosures.
What it should say: use the actual Sage ball interface rather than assuming the
method names used by python-flint. A short capability probe is cheaper than
repeated failed long checks.
Evidence: preflight.log through preflight-3.log and probe.log. This is a
portable contributor issue, not a deployment issue. All failures occurred
before the entries were submitted.