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.
