* Hamming distance between the digit string and its reverse, or
* the average of |dL − dR| over mirrored pairs.
* L1 distance, or
* KL divergence, etc.
* mutual information,
* correlation / covariance, etc.,
to see how strongly the mirrored positions are coupled.
* the overall digit distribution, or
* digit distributions on subranges,
to quantify “how uniform / random-like” the digits are.
* autocorrelation,
* simple spectral properties,
to see whether there are nontrivial patterns.
* Use an explicit big-int representation as an array of machine words, e.g. `u32` / `u64` with base 10, 10⁴, 10⁹, etc.
* Implement reverse-and-add directly on that array:
* manual big-int addition,
* mirrored index access for the reverse,
with no `int → string → int` conversions in the hot loop.
* Option A: store true decimal digits (`0..9`) in memory.
* Then SDI is just a linear scan over the digit array.
* Even 1M decimal digits is only ~1 MB, so it’s not a memory problem.
* Option B: store a larger base internally (e.g. 10⁹ per limb),
* and only at *sample steps* expand to decimal digits while simultaneously computing SDI, then discard.
The goal isn’t to record SDI on *every* iteration at huge depths, but to take occasional snapshots of the “state”:
* For example: sample at steps 0, 10k, 20k, 30k, … (or 0, 100k, 200k, …).
* That way, even if each SDI evaluation is O(N) in the number of digits, the overall overhead remains tiny compared to the cost of the core big-int reverse-and-add at extreme depths.
If someone with experience in high-performance big-int (GMP/MPIR, or Rust big-int libraries) has ideas on:
* a clean way to integrate “occasional decimal-digit snapshots” into an existing 196-style search, or
* a good data layout for this use case,
I’d be very interested — either to adapt an existing codebase, or to benchmark a dedicated SDI-sampling version against the classic implementations.