Friday, 6 February 2026

A Correction

After creating my post Number's Divisors to Sequence Algorithm, I was feeling satisfied. I'd gotten Gemini to create a neat little table for me. It showed the record lengths reached by numbers under the algorithm in the range up to one million but suffered from the fact that it was simply wrong. Here is the original table:

Number     | Length     | Status
-----------------------------------
2          | 5          | New Record!     
3          | 8          | New Record!     
6          | 10         | New Record!     
11         | 21         | New Record!     
22         | 23         | New Record!     
44         | 25         | New Record!     
50         | 28         | New Record!     
99         | 32         | New Record!     
125        | 33         | New Record!     
206        | 34         | New Record!     
350        | 37         | New Record!     
463        | 44         | New Record!     
487        | 46         | New Record!     
974        | 48         | New Record!     
1375       | 51         | New Record!     
1573       | 52         | New Record!     
1625       | 60         | New Record!     
5200       | 62         | New Record!     
14157      | 63         | New Record!     
16879      | 64         | New Record!     
18747      | 67         | New Record!     
39325      | 70         | New Record!     
89237      | 71         | New Record!     
151911     | 75         | New Record!     
563553     | 77         | New Record!     
803133     | 82         | New Record!  

Fortunately I spotted the problem when looking at the trajectory of the number associated with my diurnal age: 28068. It showed a length of 201, far in excess of the 82 associated with 803133. Furthermore, the algorithm only counted up to 201 and so the sequence was longer than that.

Naturally I confronted Gemini about the problem and here was its response:
The Reason for the DiscrepancyThe sequence for 28068 exhibits a behavior known as a Cunningham Chain.Your rule if is_prime: number = number * 2 + 1 matches the definition of a Cunningham Chain (where $p \to 2p+1$).If the sequence hits a "vein" of consecutive primes (e.g., a chain of 40 primes), the number grows by a factor of $2^{40}$ (approx. 1 trillion). My previous Python code had a safety brake: if number > \(10^12\): break. 28068 likely skyrockets past  one trillion ($10^{12}$) very quickly. My code hit this safety limit and stopped counting, reporting a truncated (incorrect) length.
Gemini proposed modifications to the code but these overtaxed the Jupyter notebook and it got stuck at a point shown in Figure 1.


Figure 1

Eventually I decided to get Gemini to write the code for just a single number as input and not a range. Even this proved too much for the Jupyter notebook. I don't know whether the sequence for 28068 goes on forever or not but I do know that the original algorithm that Gemini provided me with was flawed. It was only by chance that I found this out so caution is advised in accepting anything Gemini offers up. I'm commented in the past on its coding limitations.

The failure of the algorithm to reach completion is attributed to Cunningham chains so I'd thought I'd better look back at that topic. It turns out that the longest known Cunningham chain of the first kind (\(2p+1\) is 17 primes long so why does Gemini mention chains of 40 primes when none are known? Nonetheless, it's likely that the \(2p+1\) rule that I'm applying to prime numbers does lead quickly to very large number. My choice of this rule was quite arbitrary. Given that \(4k+1\) and \(4k-1\) primes are pretty much in equal abundance, I could apply an alternative rule such as the following to a prime \(p\):
  • if \(p \pmod 4 \equiv 1\) then \(p \rightarrow 2 \times p +1 \)
  • if \(p \pmod 4 \equiv 3\) then \(p \rightarrow (p -1 )/2 \)
This should keep the progressive numbers from growing too large. I should do this with the factors as well (see earlier posts Number's Factors to Sequence Algorithm 1 and Number's Factors to Sequence Algorithm 2). Figure 2 shows the record breaking numbers under these new rules (up to one million).


Figure 2: permalink

In summary, the record breaking numbers are 1, 2, 4, 13, 17, 34, 50, 98, 294, 650, 722, 2166, 4751, 5313, 9502, 11979, 19773, 46137, 125229, 257049, 385573, 714025.

I also got Gemini to write the code for the input of a single number and the trajectory of the number as output. Let's use 28068 as an example. Figure 2 shows the output.


Figure 3: permalink

No comments:

Post a Comment