Hi Eric, The last term in the sequence appears to be 8945, with a total of 2024 terms (tested to a(2000000)). Of course there may be errors in my code, but I think I got it right. I didn't get exactly the same results you did though, for example 1118 does not appear in my output. You can look at the output here: http://unbecominglevity.blogharbor.com/supplements/tsf_output.txt And the VB code used to generate it here: http://unbecominglevity.blogharbor.com/supplements/tsf_vb_code.txt The output is divided into 3 sections, the first is just a list of all the terms, the second is the final counts for each digit, and the third is "Eric's format"--the list of terms again which I attempted to format in the same way you did. A note on the "final values for each digit" section of the output: these are the counts of the number of times each digit appeared in the sequence, *not* the last term which ended with that digit. For example the last term ending in 0 was 5890, but other subsequent terms included 0 (for example 6008), so the count for any digit keeps going up until the last term of the sequence is found. The largest terms ending with each digit appear to be: 5890, 8201, 8312, 8623, 8734, 8495, 7756, 6697, 6778, 5979 -- Chuck Seggelin ----- Original Message ----- From: "Eric Angelini" <keynews.tv@skynet.be> To: "math-fun" <math-fun@mailman.xmission.com>; <seqfan@ext.jussieu.fr> Sent: Tuesday, February 22, 2005 6:26 AM Subject: True So Far Hello math-fun and seqfan, I've just sent this to the OEIS : 10 12 13 14 15 16 17 18 19 20 23 24 25 26 27 28 29 30 34 35 36 37 38 39 40 45 46 47 48 49 50 56 57 58 59 60 67 68 69 70 78 79 80 89 90 90 102 103 104 105 106 107 108 109 112 113 114 115 116 117 118 119 123 124 125 126 127 128 129 134 135 136 137 138 139 145 146 147 148 149 156 157 158 159 167 168 169 178 179 180 189... [more hand calculated terms here (hope no errors)]: http://www.cetteadressecomportecinquantesignes.com/TrueSoFar.htm Description : "True so far"-sequence. Last digit of a(n) must be seen as a glyph and preceding digits as a quantity. So "10" reads [one "0"] and "12" [one "2"] -- which are both true statements: there is only one "0" glyph so far in the sequence when [10] is read, and there is only one "2" glyph when [12] is read. The sequence is built with [a(n+1)-a(n)] being minimal and a(n+1) always "true so far". This explains why integers [11], [21], [22], [31], etc. are not in: their statements are false. The nice substring ...1112,1113,1114,1115,1116,1117 1118... appears in the sequence -- which means that so far the whole sequence has used 111 "2", 111 "3", 111 "4", 111 "5", 111 "6", 111 "7" and 111 "8"... Question which ruined my sleep tonight: « Will the sequence ever stop? » ... my intuition says yes... ... could someone compute this and check for some more integers? Thanks, É.

"Eric Angelini" <keynews.tv@skynet.be> wrote: :Description : : : "True so far"-sequence. Last digit of a(n) must be seen : as a glyph and preceding digits as a quantity. So "10" : reads [one "0"] and "12" [one "2"] -- which are both true : statements: there is only one "0" glyph so far in the : sequence when [10] is read, and there is only one "2" : glyph when [12] is read. The sequence is built with : [a(n+1)-a(n)] being minimal and a(n+1) always "true so : far". This explains why integers [11], [21], [22], [31], : etc. are not in: their statements are false. : : The nice substring ...1112,1113,1114,1115,1116,1117 1118... : appears in the sequence -- which means that so far the : whole sequence has used 111 "2", 111 "3", 111 "4", 111 "5", : 111 "6", 111 "7" and 111 "8"... [...] I think it would be fairer to call this "about to be true", and interesting to consider also an "already true" sequence, in which we include, say, "1234" if the *preceding* sequence includes 123 '4's. The latter can also be generalised to base b, and also varies depending on whether a(0) is chosen as '0' or '1'. Eg starting at 0: base 2: 0 1 2 4 7 8 14 16 23 26 30 32 42 48 56 62 64 75 82 89 96 101 109 116 base 3: 0 1 2 3 5 6 9 11 14 17 18 24 25 27 31 38 41 42 45 50 51 54 63 68 69 baes 4: 0 1 2 3 4 6 7 8 11 12 16 18 19 22 23 26 27 31 32 39 40 43 44 48 55 56 base 10: 0 1 2 3 4 5 6 7 8 9 10 12 13 14 15 16 17 18 19 20 23 24 25 26 27 28 .. and starting at 1: base 2: 1 3 7 13 19 25 31 41 47 57 65 69 75 83 91 101 109 119 131 137 143 153 base 3: 1 2 4 5 8 13 14 17 23 29 32 35 41 44 50 56 62 67 74 76 82 88 92 95 98 base 4: 1 2 3 5 6 7 10 11 15 21 22 23 26 27 31 38 39 43 47 55 62 66 70 71 74 base 10: 1 2 3 4 5 6 7 8 9 11 12 13 14 15 16 17 18 19 22 23 24 25 26 27 28 29 I think these sequences are always infinite. I'm unsure how many of them merit entries in the OEIS. Starting at 1 also leads to the interesting question whether the '0' digits ever get sufficiently represented to be included in the sequence (ie whether there exists an a(n) divisible by b in the sequence for any base b); empirical evidence from some brief playing suggests not. In case anyone is interested, the perl code below can be used to investigate all these sequences. Hugo van der Sanden --- #!/usr/bin/perl -w use strict; use integer; my $start = 1; # start at 0 or 1 (irrelevant unless $include is 0) my $include = 0; # include (1) or exclude (0) the about-to-be-chosen number my $base = 10; # the base to work in $| = 1; print "base $base (start=$start, include=$include): "; my @digit = (0) x $base; for (my $n = $start; 1; ++$n) { my $digit = $n % $base; my $count = $n / $base; if ($include) { next if $count <= $digit[$digit]; } else { next if $count != $digit[$digit]; } my @d2 = basedig($n); if ($include) { next if $count != $digit[$digit] + $d2[$digit]; } print "$n "; $digit[$_] += $d2[$_] for 0 .. $base-1; } sub basedig { my $n = shift; my @d = (0) x $base; do { ++$d[$n % $base]; $n /= $base; } while $n; @d; }