From Newsgroup: rec.puzzles

Complete this sequence:

_, _, _, _, _, _, _, _, _, 3888, 42768, 513216, 667188, 934632,
141948, 2271168, 3869856, 6965748, 132349212, 264698424, ...

Yup, I'd like terms 1-9.

Bonus points for the mathmos: give an expression for how quickly this
series grows: how many digits would you expect the 1000th, 10000th,
100000th, and 1000000th terms to have?

Phil
(And those who know where to look can get instant access to the answers)
--
We are no longer hunters and nomads. No longer awed and frightened, as we have gained some understanding of the world in which we live. As such, we can cast aside childish remnants from the dawn of our civilization.
-- NotSanguine on SoylentNews, after Eugen Weber in /The Western Tradition/
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: rec.puzzles

On Fri, 28 Aug 2026 00:22:36 +0300, Phil Carmody wrote:

Yup, I'd like terms 1-9.

Nice. I'm okay for the first part. I'll have a think about the second
part.
--
David Entwistle
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: rec.puzzles

In article <8733vz45sz.fsf@asdf.ee>, Phil Carmody <pc+usenet@asdf.org> wrote: >Complete this sequence:

_, _, _, _, _, _, _, _, _, 3888, 42768, 513216, 667188, 934632,
141948, 2271168, 3869856, 6965748, 132349212, 264698424, ...

Even given the first 9 terms, until we get 141948 there's still some
doubt about what the sequence is.

-- Richard
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: rec.puzzles

In article <116so5c$4t1g$1@artemis.inf.ed.ac.uk>,
Richard Tobin <richard@cogsci.ed.ac.uk> wrote:

1000 167268718788585637957754176512
10000 115561287648644129422797664757359949255136
100000 1136141149823685669283941799894965343754256
1000000 1114828839832196352142477728158415189411298271623636456323512734248

Another bonus question: why do those all begin with 1?

-- Richard
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: rec.puzzles

In article <8733vz45sz.fsf@asdf.ee>, Phil Carmody <pc+usenet@asdf.org> wrote:

Bonus points for the mathmos: give an expression for how quickly this
series grows: how many digits would you expect the 1000th, 10000th,
100000th, and 1000000th terms to have?

1000 167268718788585637957754176512
10000 115561287648644129422797664757359949255136
100000 1136141149823685669283941799894965343754256
1000000 1114828839832196352142477728158415189411298271623636456323512734248

Spoiler space
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

[Waves hands]

Call the Nth term T(N). It has log10(T(N)) digits.

Let's pretend that multiplying T(N) by N+1 produces a random sequence
of digits log10(N) longer than T(N). On average a tenth of these will
be removed. So T(N+1) has on average

9/10 (log10(T(N)) + log10(N))

digits. So if log10(N) is less than log10(T(N))/10 the number of digits
will tend to reduce, otherwise it will tend to increase. We will get equilibrium when log10(T(N)) = 10 log10(N), or T(N) = N^10.

-- Richard
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: rec.puzzles

On Fri, 28 Aug 2026 19:49:39 -0000 (UTC), Richard Tobin wrote:

Another bonus question: why do those all begin with 1?

My description is messy, but possibly something along the lines of:

Vs jr pbafvqre gur agu grez, nf a nccebnpurf n cbjre bs gra, gura gur cebonovyvgl bs gur vavgvny cebqhpg, orsber mrebf ner erzbirq, pbagnvavat
n mreb vf (cbffvoyl) 1 - (9/10)^q, jurer q vf gur ahzore bs qvtvgf va gur cebqhpg. Guvf vf yrff guna bar, ohg nccebnpurf bar nf q orpbzrf ynetr. Gur vzcnpg ba gur erfhygvat ahzore (gur aba-mreb snpgbevny) vs bar be zber
mrebf ner erzbirq vf rdhvinyrag gb qvivfvba ol n cbjre bs gra sbyybjrq ol
gur nqqvgvba bs 9/10 bs nyy gur qvtvgf gb gur evtug bs gur mreb. Gur vf rdhvinyrag gb qvivfvba ol n ahzore fbzrjung yrff guna gra. Gur cebqhpg bs gurfr gjb vasyhraprf vf whfg fyvtugyl ynetre guna n cbjre bs gra naq chgf
n bar va gur zbfg fvtavsvpnag qvtvg.
--
David Entwistle
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: rec.puzzles

In article <1170qqc$3svim$1@dont-email.me>,
David Entwistle <qnivq.ragjvfgyr@ogvagrearg.pbz> wrote:

Another bonus question: why do those all begin with 1?

Here's my explanation.

Jr'er nccebnpuvat n cbjre bs gra fb A ortvaf jvgu 9. Fhccbfr gung
F(A) ortvaf jvgu 1, fb vg'f orgjrra 111... naq 199... Gura (A+1) F(A)
jvyy or nyfb ortva jvgu 1 naq fb jvyy F(A+1), naq orpnhfr gur mrebrf
ner erzbirq vg jvyy or ng yrnfg 111... ntnva.

Gung vf, vs F(A) rire ortvaf jvgu bar jura A ortvaf jvgu 9,
fhpprrqvat inyhrf jvyy nyfb ortva jvgu bar hagvy nsgre A
ernpurf gur arkg cbjre bs gra. Vg trgf "genccrq" va inyhrf
ortvaavat jvgu 1.

Guvf qbrfa'g unccra jvgu gur snpgbevny shapgvba, orpnhfr n inyhr
ortvaavat jvgu 1 znl ortva jvgu 10. Sbe rknzcyr, 95! ortvaf
1032... fb 96! ortvaf 99... naq vg rfpncrf gur genc.

-- Richard
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: rec.puzzles

In article <116so5c$4t1g$1@artemis.inf.ed.ac.uk>,
Richard Tobin <richard@cogsci.ed.ac.uk> wrote:

In article <8733vz45sz.fsf@asdf.ee>, Phil Carmody <pc+usenet@asdf.org> wrote:

Bonus points for the mathmos: give an expression for how quickly this >>series grows: how many digits would you expect the 1000th, 10000th, >>100000th, and 1000000th terms to have?

1000 167268718788585637957754176512
10000 115561287648644129422797664757359949255136
100000 1136141149823685669283941799894965343754256
1000000 1114828839832196352142477728158415189411298271623636456323512734248

Some more values:

10000000 11369436279154838514569735263935293883868829566247715738211151771131572
100000000 111892791617298738664974975189485467758117557576382896636315253382745554253755326351157248
1000000000 1116261265478134227397932673264932225965498386448886515479288939874744881126242351158526
10000000000 11115592733643186436631888321432897482694847579734846162383383488896288842919911525326836588516428648
100000000000 11116293777537955511862692148592837467885749363711973614574829888862236243951212275792322432572882368424424384

It's amazing what you can do with brute force these days.

In terms of number of digits:

10^3 30
10^4 42
10^5 43
10^6 67
10^7 71
10^8 90
10^9 88
10^10 101
10^11 110

Which is in accordance with my hand-waving estimate of the growth rate
and Sloane's "very crude calculation".

-- Richard
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: rec.puzzles

richard@cogsci.ed.ac.uk (Richard Tobin) writes:

In article <8733vz45sz.fsf@asdf.ee>, Phil Carmody <pc+usenet@asdf.org> wrote:

Bonus points for the mathmos: give an expression for how quickly this >>series grows: how many digits would you expect the 1000th, 10000th, >>100000th, and 1000000th terms to have?

So if log10(N) is less than log10(T(N))/10 the number of digits
will tend to reduce, otherwise it will tend to increase. We will get equilibrium when log10(T(N)) = 10 log10(N), or T(N) = N^10.

Yup, that's the heuristic I arrived at too. It doesn't seem to deviate far:

10000000: [71]=11369436279154838514569735263935293883868829566247715738211151771131572
100000000: [90]=111892791617298738664974975189485467758117557576382896636315253382745554253755326351157248

I think I have a heuristic for your followup:

Another bonus question: why do those all begin with 1?

As the numbers get multiplied by 997..., 998..., 999..., they shrink
towards 1, but cannot cross that barier. Were they able to flip from
11... to 109... they'd instead become 19.... However, as the
multiplicand grows beyond a couple of digits, even that gulf is
uncrossable, so the 111... instead would fail to flip to 1109 and hit
119... instead. Thus they are ultimately destined to just bounce around somewhere just above 111...

I think this should be the 10^10th term:
10000000000: [101]=11115592733643186436631888321432897482694847579734846162383383488896288842919911525326836588516428648

In some ways, I'm surprised the string of leading 1s across the
odometric thresholds isn't growing as fast as I would expect it to.

The longest value I reached was term 7563152347 at 133 digits.
The shortest outliers are in the 50+ digits range:

[54]=19157 - 9992661725
[53]=14828 - 9547032791
[52]=18363 - 9428280749
[51]=13518 - 9323809783
[50]=12069 - 8444484882

[length]=first appearance - last appearance

So I'm sure length 54 will be seen again, not so sure about the others.

Source, for the interested, follows. (Took <4 hours on a repurposed
set-top box, so it's probably easier to just start it running on a fast
machine rather than modifying the code to be able to resume.)

Phil

----- 8< --- BEGIN: ftcrl.c ---
#if 0
exec /usr/bin/tcc -run "$0" "$@"
#endif

#define LMAX 400
#include <stdio.h>
#include <stdlib.h>
#include <stdbool.h>

unsigned int mul(unsigned char *buf, unsigned int l, unsigned long m)
{
unsigned long carry=0;
unsigned int pin, pout;
while(m%10==0) { m/=10; }
for(pout=pin=0; pin<l; ++pin) {
unsigned long v=buf[pin]*m+carry;
if(v%10) { buf[pout++]=v%10; }
carry=v/10;
}
while(carry) {
while(carry%10==0) { carry/=10; }
buf[pout++]=carry%10;
carry/=10;
}
return pout;
}
void print(unsigned long n, const unsigned char *buf, unsigned int l)
{
printf("%lu: [%u]=", n, l);
while(l-->0) { putchar(buf[l]+'0'); }
puts("");
}
int main(int argc, char **argv)
{
unsigned long max=argc>1?strtoull(argv[1],NULL,0):24;
int verbosity=argc>2?atoi(argv[2]):1;
unsigned char buffer[LMAX]={1,0};
unsigned int len=1;
unsigned long n=0;
unsigned long lastl[LMAX]={0};
unsigned long firstl[LMAX]={0};
unsigned int lmax=0;
while(n<max) {
n++;
len=mul(buffer, len, n);
if(verbosity>1||n%1000000==0) { print(n,buffer,len); }
else if(verbosity==1||n%100000==0) { printf("%lu: %u\n", n, len); }
lastl[len]=n;
if(len>lmax) { lmax=len; }
if(!firstl[len]) { firstl[len]=n; }
}
if(verbosity<=1) { print(n, buffer, len); }
do {
printf("[%u]=%lu - %lu\n", lmax, firstl[lmax], lastl[lmax]);
} while(lmax-->0);
}
----- 8< --- END: fctrl.c ---
--
We are no longer hunters and nomads. No longer awed and frightened, as we have gained some understanding of the world in which we live. As such, we can cast aside childish remnants from the dawn of our civilization.
-- NotSanguine on SoylentNews, after Eugen Weber in /The Western Tradition/
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: rec.puzzles

richard@cogsci.ed.ac.uk (Richard Tobin) writes:

Some more values:
10000000000 11115592733643186436631888321432897482694847579734846162383383488896288842919911525326836588516428648

That's what I like to see, given my:

10000000000: [101]=11115592733643186436631888321432897482694847579734846162383383488896288842919911525326836588516428648

Mad props for going this far:

100000000000 11116293777537955511862692148592837467885749363711973614574829888862236243951212275792322432572882368424424384

It's amazing what you can do with brute force these days.

I guess my code could get there in about a day if I ran it on a faster
machine. This box has a 1.66 GHz low power AMD embedded processor and
took just under 4 hours for the above. I don't really see a way of
getting any significant speed-ups over my simple code, as it's
inherently a digit-by-digit operation.

Phil
--
We are no longer hunters and nomads. No longer awed and frightened, as we have gained some understanding of the world in which we live. As such, we can cast aside childish remnants from the dawn of our civilization.
-- NotSanguine on SoylentNews, after Eugen Weber in /The Western Tradition/
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: rec.puzzles

In article <87ld9l2v0y.fsf@asdf.ee>, Phil Carmody <pc+usenet@asdf.org> wrote:

100000000000

11116293777537955511862692148592837467885749363711973614574829888862236243951212275792322432572882368424424384

It's amazing what you can do with brute force these days.

I guess my code could get there in about a day if I ran it on a faster >machine. This box has a 1.66 GHz low power AMD embedded processor and
took just under 4 hours for the above. I don't really see a way of
getting any significant speed-ups over my simple code, as it's
inherently a digit-by-digit operation.

I left mine running so I should have 10^12 in a couple of days.

Your program looks more efficient than mine as I did a separate pass
to remove the zeroes, but I'm running it on a faster processor.

-- Richard
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: rec.puzzles

In article <11767tn$a05q$1@artemis.inf.ed.ac.uk>,
Richard Tobin <richard@cogsci.ed.ac.uk> wrote:

I left mine running so I should have 10^12 in a couple of days.

1000000000000 11112283294164421427139712713911119137713789962556232174246622824727475247553384558863822468976276345356971235486752738628

-- Richard
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: rec.puzzles

In article <117gpt2$fokt$1@artemis.inf.ed.ac.uk>,
Richard Tobin <richard@cogsci.ed.ac.uk> wrote:

1000000000000 11112283294164421427139712713911119137713789962556232174246622824727475247553384558863822468976276345356971235486752738628

I've uploaded a file with the values for 10^k to OEIS, it's currently
a draft edit to https://oeis.org/A243657

-- Richard
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: rec.puzzles

On Sat, 5 Sep 2026 10:51:08 -0000 (UTC), Richard Tobin wrote:

I've uploaded a file with the values for 10^k to OEIS, it's currently a
draft edit to https://oeis.org/A243657

Your edit is now approved.
--
David Entwistle
--- Synchronet 3.22a-Linux NewsLink 1.2