Thanks for the thoughtful questions — here’s how I see things at the moment.

---

### 1. Similar work (Lychrel candidates + digit symmetry metrics)

There’s a lot of well-known computational work around 196 and Lychrel candidates in general:

* pushing reverse-and-add depth, * cataloging candidate roots over large ranges, * classic projects like John Walker’s “196 Palindrome Quest” and p196.org, etc.

I’ve been looking at that side of things as background.

What I haven’t really seen (so far) is something that does exactly what I’m doing here, namely:

> at each step, measure some *left–right digit symmetry/asymmetry metric*, > and plot that as a time series along the 196 chain.

So SDI, as I’m using it, isn’t meant as a standard or established tool — it’s more like an ad-hoc probe I built to see whether the 196 chain visibly behaves differently from a “normal” case like 89.

If anyone knows of prior work that tracks a similar per-step “symmetry defect” over a Lychrel candidate, I’d really like to see it.

---

### 2. Better / more standard metrics

I completely agree SDI is a toy metric. I chose it for very pragmatic reasons:

* easy to compute from the decimal representation, * has a clear mirror interpretation (pairing left/right digits), * and naturally goes to 0 on a palindrome.

If I wanted to take this more seriously, some obvious directions would be:

* *Direct distances* Instead of the mod-2 / mod-5 trick, use something like:

  * Hamming distance between the digit string and its reverse, or
  * the average of |dL − dR| over mirrored pairs.

* *Left vs right distributions* Build digit histograms for left and right halves and compare them via:

  * L1 distance, or
  * KL divergence, etc.

* *Correlation / information-theoretic view* Treat pairs (i, L−1−i) as samples from a joint distribution and measure:

  * mutual information,
  * correlation / covariance, etc.,
    to see how strongly the mirrored positions are coupled.

* *Entropy-type measures* Shannon entropy of:

  * the overall digit distribution, or
  * digit distributions on subranges,
    to quantify “how uniform / random-like” the digits are.

* *Time-series style analysis* View the digits as a sequence 0–9 and look at:

  * autocorrelation,
  * simple spectral properties,
    to see whether there are nontrivial patterns.

In other words, SDI is just a cheap, first exploratory probe. I’m absolutely open to replacing it with something more standard. If there’s a specific metric you think would be more meaningful here (or more familiar from information theory / statistics / dynamical systems), I’d be happy to try it on the same data and compare.

---

### 3. Scaling this in C / Rust

I agree: with Python, what I’m doing now is fine for ~50k steps / ~20k digits, but nowhere near the kind of depths that the classic 196 palindrome quests reached. To go there, the implementation really has to change.

Rough sketch of what I have in mind:

1. *Representation*

   * 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.

2. *SDI computation strategy*

   * 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.

3. *Sampling frequency*

   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.

4. *Collaboration / feedback*

   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.

---

That’s roughly where I’m at right now. I’m happy to refine any of this or try specific metrics if you have something particular in mind.