[seqfan] Re: Are these really the same?

[israel at math.ubc.ca]

The actual definition of "normal" applies to real numbers, not to integers. 
It is believed that sqrt(2), for example, is normal. This would mean for 
example that floor(10^n*sqrt(2)) would be "normal" in your sense for large 
n. But its square, which would be very close to 2*10^(2*n), would not be 
"normal". So x^2 does not preserve normality.

Robert Israel
University of British Columbia


On Jan 8 2012, David Wilson wrote:

>The key observation is that as x grows, so does digitsum(x), though not 
>in an erratic way that complicates finding
>proofs and counterexamples. Most large numbers are "normal" in the sense 
>that their digits are more or less
>equidistributed, in which case digitsum(x) will be (average digit) * 
>(digits in x), or for base 10, about 4.5 * log10(x).
>
>It is easy to contrive integer functions that do not preserve normality, 
>for example, for large x, f(x) = 10^x will yield
>results predominated by the digit 0 in base 10. However, many functions 
>seem to preserve normality for large integers,
>including non-constant polynomials and powers of integers n > 1 that are 
>coprime to the base. However, proving
>that normality is preserved by a function is at present impossible.
>
>The functions x^2 and digitsum(x) are among the functions that appear to 
>preserve normality. These functions also
>generally increase without bound with increasing normal argument. One 
>would therefore intuit that for a composite
>function such as f(x) = digitsum(digitsum(digitsum(x^2)^2))), that 
>normality would be preserved by each successive
>function application, hence f(x) itself preserves normality, and grows 
>without bound (albeit very slowly) with increasing x.
>This would lead one to conclude that for sufficiently large normal 
>argument x, f(x) could be made as large as desired.
>
>In the case of your original question, a sufficiently large normal value 
>of x == 4 or 5 (mod 9) should force f(x) as large
>as desired, specifically, f(x) > 4, so f(x) = 4 shouldn't be true for 
>all x == 4 or 5 (mod 9), and by mucking around I was
>able to find an explicit f(x) > 4. However, one more application of 
>digitsum() to the f(x) expression would have rendered
>an explicit x much to large to write down, much less find. However, by 
>the uncertain reasoning above, we could be
>probability-1 certain that such an x would exist.
>
>Through a certain level of mathematical ability and familiarity with 
>this type of problem, I have developed a general
>intuition for this sort of problem, obviously shared in greater measure 
>by some of the other members of this group.
>On reading your problem, I immediately "saw" that your sequence was not 
>the same as A156638 (which I think should
>be renamed "n^2 == 7 (mod 9)" or "n == 4 or 5 (mod 9)"). Any number of 
>additional applications of digitsum() would
>not change that fact, but would make it nigh impossible to prove.
>
>On 1/8/2012 3:29 AM, Veikko Pohjola wrote:
>> Thanks a lot gentlemen. I need to admit that I intuitively knew that 
>> this would be the case but was perhaps too lazy to continue searching. 
>> The next counterexamples to be found at this level would be 31 and 40. 
>> So we can say that with this appproach, by adding the nesting of digit 
>> sums, it is possible to produce sequences whose coincidence with 
>> A156638 reaches further and further in an asymptotic way, but the 
>> sequences are never 'really the same'.
>> Veikko
>
>
>_______________________________________________
>
>Seqfan Mailing list - http://list.seqfan.eu/
>