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