[seqfan] Re: Cumulative sum of the digits used so far
M. F. Hasler
oeis at hasler.fr
Fri Oct 31 00:23:32 CET 2014
On Thu, Oct 30, 2014 at 4:10 AM, Eric Angelini <Eric.Angelini at kntv.be> wrote:
> I guess a(1) should be = 0
>> 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 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
But one also has to check ("recursively") whether N+9k also satisfies
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
More information about the SeqFan