33156a1c

By: ValentinHirschi <valentin.hirschi@gmail.com>

explain the retained GL638 confirmation maxima

Extend the existing diagnostic replay from two to four retained norms per
method to cover the actual imaginary maximum, preserving all previous
Samples and controls. Record three native traces, projected threshold
geometry, and the exact 7/6 change at the shared real maximum.

Validation: 605 native accuracy checks, 78 reuse checks, exact trace/control
agreement, 56 single-star and 12 merged-point reconstructions, and 12 native
multiplier checks. Root verified all 63 archived records against source bytes.
No MC samples, numerical tolerances or production physics changed here.
The separate precision/timing/dependency work remains unstaged.

Latest user request (verbatim):
Continue and finalize your current investigation (and also notice that it may not be best to have two integration channels active for one of the cuts here; it may be interesting to see what happens when you enable just the joint map for it); also verify that the soft gluon behaviours are fine, even without the explicit lmb channel (with these gluons part of the lmb).

Also consider comparing sampling of all channels at once (i.e. explicitly summed) vs mc'ing over them (with importance sampling). Often, the first mode leads to less bias. (but only do that last part after the optimisation round below)

Then, now that we have some evidence of things working well, we should aim at improving a bit the runtime, before doing more long expensive runs.

To this end:

a) The following is too inefficient:

"""
1. very generated point and its complete sampling weight are prepared at **1000-bit precision**, even for ordinary LMB channels.
2. Joint-map support checks use **2048-bit interval arithmetic**.
"""

Find a way to safely avoid *always* going to higher-arithmetic precision (launch an agent on doing research on how avoid this safely).

b) Let's compile the integrand now with SymJIT o2, and make sure we're using the latest symjit version (patch it in Cargo.toml if need be, but it's a dependency of Symbolica at this point), and use the compression mode. Measure how the timings compare w.r.t current eager mode for double-precision evaluation, but not just monocore but also in production with 20 concurrence cores (it make a difference because of L3 cache saturation potentially).

Report what's your best measure runtime (separating integrand overhead, time spent in evaluators and time spent in advanced sampling) in this best setup you landed on.

Timeline