Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > rec.puzzles > #28046 > unrolled thread

series puzzle

Back to article view | Back to rec.puzzles

Contents

  series puzzle Phil Carmody <pc+usenet@asdf.org> - 2026-08-28 00:22 +0300
    Re: series puzzle David Entwistle <qnivq.ragjvfgyr@ogvagrearg.pbz> - 2026-08-28 08:56 +0000
    Re: series puzzle richard@cogsci.ed.ac.uk (Richard Tobin) - 2026-08-28 17:54 +0000
    Re: series puzzle richard@cogsci.ed.ac.uk (Richard Tobin) - 2026-08-28 19:39 +0000
      Re: series puzzle richard@cogsci.ed.ac.uk (Richard Tobin) - 2026-08-28 19:49 +0000
        Re: series puzzle David Entwistle <qnivq.ragjvfgyr@ogvagrearg.pbz> - 2026-08-30 08:49 +0000
          Re: series puzzle richard@cogsci.ed.ac.uk (Richard Tobin) - 2026-08-30 11:51 +0000
      Re: series puzzle richard@cogsci.ed.ac.uk (Richard Tobin) - 2026-08-30 12:06 +0000
        Re: series puzzle Phil Carmody <pc+usenet@asdf.org> - 2026-09-01 12:14 +0300
          Re: series puzzle richard@cogsci.ed.ac.uk (Richard Tobin) - 2026-09-01 10:03 +0000
            Re: series puzzle richard@cogsci.ed.ac.uk (Richard Tobin) - 2026-09-05 10:11 +0000
              Re: series puzzle richard@cogsci.ed.ac.uk (Richard Tobin) - 2026-09-05 10:51 +0000
                Re: series puzzle David Entwistle <qnivq.ragjvfgyr@ogvagrearg.pbz> - 2026-09-06 07:52 +0000
      Re: series puzzle Phil Carmody <pc+usenet@asdf.org> - 2026-08-31 22:22 +0300

#28046 — series puzzle

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/

[toc] | [next] | [standalone]

#28048

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

[toc] | [prev] | [next] | [standalone]

#28049

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

[toc] | [prev] | [next] | [standalone]

#28050

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

[toc] | [prev] | [next] | [standalone]

#28051

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

[toc] | [prev] | [next] | [standalone]

#28055

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

[toc] | [prev] | [next] | [standalone]

#28056

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

[toc] | [prev] | [next] | [standalone]

#28057

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

[toc] | [prev] | [next] | [standalone]

#28059

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/

[toc] | [prev] | [next] | [standalone]

#28060

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

[toc] | [prev] | [next] | [standalone]

#28061

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

[toc] | [prev] | [next] | [standalone]

#28062

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

[toc] | [prev] | [next] | [standalone]

#28063

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

[toc] | [prev] | [next] | [standalone]

#28058

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/

[toc] | [prev] | [standalone]

Back to top | Article view | rec.puzzles

csiph-web