[seqfan] Re: Cumulative sum of the digits used so far

[Bob Selcoe]

>> I guess a(1) should be = 0
>
> I agree.

I also agree. And I agree the sequence should be added to OEIS.

>> It seems to me that there is no upper limit on the depth needed to
> >look forward, nor on the possible step size.

I think there are limits.  Perhaps I'm wrong, but this is what I see 
happening here:

Given N = a+10b+100c, gaps of 18 occur after 180k+81 and 180(k+1), k>=0, 
until reaching greatest multiple of 9 less than c+1; else gaps of 9 occur. 
So N=81 is c=0, k=0 (from first equation), 81+18 = 99 is next in sequence 
and greatest multiple of 9 less than c=1, so 108 is next in sequence, 
followed by 117, 126, etc., adding 9 until 180, which is k=0 (from second 
equation), then add 18.

 N=540 is c=5, k=2 (second equation), so the sequence continues 558, 576, 
594 (greatest multiple of 9 less than c=6), so next in sequence is 603, 612, 
621 (k=3, first equation), followed by gaps of 18 (639, 657, 675, 693) then 
gaps of 9 (702, 711, 720) and gaps of 18 (738, 756...).

As the number of digits in N increases (a+10b+100c+1000d...+10^z*j), the 
largest gaps will be 9z (1<=z<=10), with all other gaps from 9 to 9(z-1) 
occurring in the sequence.

The gap of 9z occurs first between and 10^z-9z-1 and 10^z-1: that is,  from 
0 to 9 (z=1); 81 to 99 (z=2); 972, 999 (z=3); 9963, 9999;  99954, 99999... 
up to 10^10-91, 10^10-1 (gap of 90, z=10).

So M.F. is correct that the gap after 972 is 27 to 999 - the first gap of 
27.  There will be gaps of 9, 18 and 27 thereafter until 9963, then gaps of 
9, 18, 27 and 36 until 99954, etc.

There are gap sub-patterns which appear to follow along similar lines to the 
two equations above, which get more complicated as the number of digits in N 
increase (I haven't worked them out sufficiently but they seem hard to 
describe - for me, anyway).  It's clear they are dependent on sums of groups 
of adjacent digits, as modulo 9.

 With some work I think it's possible to find an algorithm, though perhaps 
it is quite complicated.

Cheers,
Bob Selcoe

--------------------------------------------------
From: "M. F. Hasler" <oeis at hasler.fr>
Sent: Thursday, October 30, 2014 6:23 PM
To: "Sequence Fanatics Discussion list" <seqfan at list.seqfan.eu>
Subject: [seqfan] Re: Cumulative sum of the digits used so far

> On Thu, Oct 30, 2014 at 4:10 AM, Eric Angelini <Eric.Angelini at kntv.be> 
> wrote:
>> I guess a(1) should be = 0
>
> I agree.
>>> Le 30 oct. 2014 à 08:22, "Eric Angelini" <Eric.Angelini at kntv.be> a écrit 
>>> :
>>> Hello SeqFans,
>>> I think this is the beginning of the slowest ever-increasing sequence
>>> where a(n) is the sum of the digits present so far in the sequence,
>>> including the digits of a(n):
>>>
>>> 9, 18, 27, 36, 45, 54, 63, 72, 81, 99, 108, 117, 126, 135, 144, 153, 
>>> 162,
>>> 171, 180, 198, 207, 216, 225, 234, 243, 252, 261, 279, 297, 306, 315,
>>> 324, 333, 342, 351, 360, 378, 396, 405, 414, 423, 432, 441, ...
>>>
>>> I'm not sure, though, because you have usually gaps of 9 units between
>>> two consecutive terms, and sometimes gaps of 18 units... I don't know 
>>> how
>>> to handle algorithmically those.
>
> Indeed the terms must be multiples of 9 because the digital sum of N
> is congruent to N (mod 9).
> One must check whether digitsum(N+9k)=9k for some k>=1, to know
> whether N is an allowed value.
> For example, 90 is not allowed because
> 90+a+b+c = 100a+10b+c <=> 90=99a+9b does not have a solution for a,b,c<10.
> [Here we see that the [100]a was not relevant; in the same way for a
> general N(=a(n)) one does not need to consider more than D digits if
> 10^D>N+1.]
>
> But one also has to check ("recursively") whether N+9k also satisfies
> this condition.
> e.g., after 261, the term 270 (with digitsum = 9 = 270-261) would be
> allowed according to the first criterium:
> 270+9=279 does not work but 270+18=288 is OK (digital sum 18 = 288-270);
> however, this potential successor 288 does not have a successor:
> 288+9=297 hasn't digital sum 9 but 18,
> 288+18 = 306 hasn't digital sum 18 but only 9,
> and thereafter the digital sum cannot "catch up" any more because it
> cannot increase more than 9 at each increase of k.
> Therefore 288 is not a possible value and cannot be successor of 270.
> Thereafter, 270+27=297 has digital sum of 18 < 27 and for the same
> reason as above there cannot be a larger successor.
> So 270 has no "allowed" successor and is to be banned, therefore 261
> is followed by 261+18 = 279 with digital sum 18.
>
> It seems to me that there is no upper limit on the depth needed to
> look forward, nor on the possible step size.
> For example, looking forward only 3 steps one gets stuck with 630 ;
> looking forward (at least) 4 steps one finds that 621 must instead be
> followed by 639;
> unless looking forward at least 5 steps, one then gets stuck at 810, etc.
>
> Also, concerning the step size, it seems to me that a gap of 27 is 
> necessary
> after 972 to get 999 and continue. (972+18 = 990 cannot be followed by
> 999 with digital sum too large, nor by 1008 or a larger term with
> digital sum less than the gap.)
> From there on it seems clear that larger and larger steps will occur
> as the size of the numbers increases.
>
> I propose the sequence as http://oeis.org/draft/A248050
>
> Maximilian
>
> _______________________________________________
>
> Seqfan Mailing list - http://list.seqfan.eu/
>