argument-selection.md

back to table · edit · history · where entries came from · files · download

3510 bytes, as of the version from 2026-10-28 03:46 (current). Recorded here, not run.

# Argument selection for T570

This build uses the coordinated skill archived in
`agents/runs/20261028T033309Z-build-skills/manifest.json`. Both archived copies
and the source snapshot have SHA-256
`e37efb7e2ededf6c1d7134c673f152f648f26e0267c556aebdf3ec65765d8b4c`.
The full manifest and verified hashes are recorded in `skill-evidence.json`.
This is the builder's justification, not an independent critique acceptance.

The only free table parameter is `k`, an integer with mathematical domain
k >= 0. Its category is `discrete_index`: k is the order of an asymptotic
correction in the large-argument expansion of the derivative of K_nu. The
index is fixed by powers z^(-k), as in DLMF 10.40.4 and 10.17.8; it does not
rename a continuous sample. The default enumeration is exactly 0,1,...,20,
in that order. There are no extra selected arguments or hidden couplings.

Each row retains the entire exact polynomial in nu, so all symbolic orders
are covered at that correction order. Nu is the indeterminate, not a sampled
parameter. The stored letter v denotes nu because the NumberDB polynomial
grammar accepts a single letter with optional digits. This agrees with T569.
The normalization is the DLMF product, with b_0=1, reduced rational
coefficients, and no absorbed overall minus sign or phase factor.

The initial prefix through k=20 covers twenty successive nonleading
corrections, through degree 40. Small corrections lead the display; the
selection is not limited to individually famous polynomials. Twenty is an
editorial bound, not a mathematical endpoint. The measured longest row is
1,209 characters at k=20; `check.measure` reports 21 entries and a 9.674 KiB
block (using its generic key wrapper). A larger prefix would lengthen already
substantial rational expressions. Readability, not storage capacity, sets the
practical bound. The four-table family already covers both fixed-order and
large-order regimes and their derivative coefficients in separate tables;
this breadth is more useful than extending this one family to much higher
correction orders. The range remains the proposal's 0..20 after measurement.

This is one exhaustive finite prefix of one discrete family. It is not a
mixed selection or an exploratory real-input reference sample. There is no
rational mesh, decimal grid, Cartesian product, or quantile computation.
The half-integers used in `checks.py` are verification nodes only; they are
not selected table entries. They determine the polynomials independently by
exact interpolation in nu^2.

Sources checked:
- DLMF 10.17.8, https://dlmf.nist.gov/10.17#E8: the coefficient product.
- DLMF 10.40.4, https://dlmf.nist.gov/10.40#E4: its correction-order meaning
  and the external minus sign in the K derivative expansion.
- DLMF 10.29.1, 10.39.2 and 10.49.12, with the modified-cylinder convention
  of 10.25(ii): recurrence and elementary half-integer verification route.
- NumberDB T116 and T199: the Bessel-polynomial normalization and its
  half-integer relation with K_nu. T569 supplies the companion a_k family.

The completeness note, Programs snippet, generator enumeration and stored
row order must all describe exactly this prefix. The independent critique
must evaluate this justification itself and fingerprint the live selection
and `generate.py`, which is self-contained and has no selection helper.
`checks.py` and `check.py` are verification code, and this note documents the
selection; including their attachment hashes is useful for evidence integrity.