Skip to content

Latest commit

 

History

History
147 lines (116 loc) · 6.11 KB

File metadata and controls

147 lines (116 loc) · 6.11 KB

Run example — bitwise regression reference

A fixed, fully-deterministic run used to verify that package changes are behavior-preserving: after any refactor, this run must reproduce the same numeric result bitwise.

  • Case: Δφ = 1.0615, leading scalar gap (sg=0), λ = 7
  • Interp: barycentric, order 28 (the script uses order 28 for λ>5)
  • Reference log: ~/data/FunBootArtifacts/logs/local_dphi1p0615_lam7_sg0_baryO28_t8_20260704_013015.log
  • Established deterministic across repeated runs: identical 4894-pivot path. The 2026-07-04 taper revert (full edge windows default; the graded taper biased gap bounds down — see barycentric_worklist.md §3.1) bit-for-bit restored the original pre-taper baseline (cb9ecbf epoch): the current hashes below equal that baseline's. The tapered epoch (2026-07-01→04, A=abfec94c…, B=87cc797b…/eee5e30c…) is superseded.

Command

cd /home/zephyr/Documents/FunBootV2
export PATH=$HOME/.juliaup/bin:$PATH

# The scan SKIPS any λ whose _final.jls already exists, and RESUMES from any
# _dynstep_NN.jls checkpoint — clear both to force a fresh run.
rm -f /tmp/l7_1p0615_local/dphi_1p0615_lam7_sg0_dyn_*.jls

LOG=/home/zephyr/data/FunBootArtifacts/logs/local_dphi1p0615_lam7_sg0_baryO28_t8_$(date +%Y%m%d_%H%M%S).log

FUNBOOT_TABLE_FILES=/home/zephyr/Movies/funtable/dphi3d_106_o12vh/dphi_1p0615.h5 \
FUNBOOT_SPINTOGAP=0 \
FUNBOOT_LAMBDA_MIN=7 FUNBOOT_LAMBDA_MAX=7 \
FUNBOOT_INTERP_METHOD=barycentric \
FUNBOOT_LTABLE_MAX_EVEN=80 FUNBOOT_LTABLE_HIGH_SPIN=100 \
FUNBOOT_COARSE_STRIDE_SCALE=3 \
FUNBOOT_CACHE_DIR=/tmp/l7_1p0615_local \
  julia --project=. -t 8 test/dphi_lambda_loop_scan.jl \
  2>&1 | tee "$LOG"

Pinned environment

Keep these identical or the low-order bits (and possibly a near-tie pivot) can shift:

host zephyr-MS-7E25
julia 1.12.6
julia threads -t 8
BLAS lbt, 16 threads
DoubleFloats 1.9.4 (compat "1.9.4"; 1.8.0–1.9.3 have the inv low-word bug, fixed in 1.9.4)
table file dphi3d_106_o12vh/dphi_1p0615.h5, 2089512152 bytes
dphi (from file) 1.0615
regulator (auto) 8.609144701419296e-24

Golden result (what must stay bitwise identical)

Human spot-check (scaled3d physical |OPE|), 78 operators, leading:

|  L  |         Δ           |         |OPE|         |
|   2 |    3.000000000000000 | 4.7233450002566e-01 |   (stress tensor, protected Δ=3)
|   0 |    3.001453284571810 | 1.1774706569296e+00 |   (leading scalar — the maximized gap)
|   2 |    4.688960427445762 | 4.8137981515877e-01 |
|   4 |    5.364682779157447 | 1.3383144093837e-01 |
|   0 |    6.084816503659162 | 1.6748624033028e-01 |

Optimal functional: λ=7, 128 entries (from Double64), ‖y‖₂ = 2.898407e+213. Simplex: 4894 pivots.

Hash A — result slice (PRIMARY: the physics deliverable)

Optimal-functional weights + scaled3d solution table, with wall-time/RSS lines stripped. A behavior-preserving change must leave this unchanged.

sha256 = 9d236b80a6af84c9f0183178bfabd48278ac537df0c5c365c5a939571d756c56

Hash B — full pivot path (SENSITIVE tripwire)

Every simplex row's deterministic columns (ite | negnum | costvar | in-Δ | in-ℓ | out-Δ | out-ℓ | cost | AUX). Catches changes to the internal trajectory even when the final answer is unchanged. A pure refactor keeps this identical; a legitimate algorithmic optimization (e.g. different tie-breaking) may change it while Hash A stays put — so treat a B-only change as "look closer", not necessarily a regression.

sha256 = 7b111aff7c30ec374317b36289efab9fd63bf251fc5dbca10fb38c472d711be3

Hash history: two behavior-changing episodes were both eventually REVERTED, restoring the original cb9ecbf baseline bits (A=9d236b80…, B=7b111aff…, 4894 pivots): (1) the graded edge taper (2026-07-01, re-pinned to A=abfec94c…/B=87cc797b…, 4858 pivots) was found to bias gap bounds down on clean tables and reverted 2026-07-04 — full edge windows are the default again (edge_order_min, see barycentric_worklist.md §3.1); (2) the DoubleFloats 1.9.1 bump (B→eee5e30c…) hit the ≥1.8.0 inv low-word bug and was pinned back to =1.7.1 (see LocalBarycentric/REGRESSION_lam11.md). Everything shipped since (LocalBarycentric extraction, perf fixes, cache deletion, checkpointing) is bitwise behavior-preserving. 2026-07-08: DoubleFloats unpinned to "1.9.4" (upstream fix released, DoubleFloats.jl#291). Validated: golden Hash A and Hash B match bit-for-bit on 1.9.4 (log local_dphi1p0615_lam7_sg0_baryO28_t8_20260708_142843.log), and the λ=11 dphi2/sg2 fingerprint oracle reads the healthy ite-28 indicator 1.1e-18 (log df194_fingerprint_lam11_20260708_143309.log).

Verify after a modification

One-shot wrapper (runs the command above, then checks both hashes; exit 0 = pass):

./check_runexample.sh                 # full run + verify
./check_runexample.sh <log-file>      # verify an existing log only

Or by hand:

LOG=<path to the new run's log>

# Hash A — must equal the golden value above (precompile chatter can land in
# the log tail on the first run after a code change; strip it)
awk '/^Optimal functional/{f=1} f' "$LOG" \
  | grep -vE 'Total wall time|Peak resident memory|Precompiling|precompiled|' \
  | sha256sum

# Hash B — full pivot path
grep -E '^\| *[0-9]+ \| *[0-9]+ \|' "$LOG" \
  | awk -F'|' '{ printf "%s|%s|%s|%s|%s|%s|%s|%s|%s|\n",$2,$3,$4,$5,$6,$7,$8,$9,$10 }' \
  | sha256sum

Do NOT compare the .jls

*_dyn_final.jls is the serialized LP (full-precision Float64/Double64 matrices). Its sha256 differs run-to-run even with no code change — same byte size, different low bits — because multithreaded BLAS reorders floating-point accumulation below the printed precision. The rounded printed tables (Hash A) absorb this noise; the raw .jls does not. Use the log hashes, not the .jls.

For a stricter full-precision determinism check, re-run single-threaded (julia -t 1 and BLAS.set_num_threads(1)), which removes the BLAS reordering — but that is slower and not what the pinned environment above uses.