4 ms·
Beginning of an outline of a proof... arc> (dedup:mapn [mod-expt 2 _ 100] 2 100) (4 8 16 32 64 28 56 12 24 48 96 92 84 68 36 72 44 88 76 52) That's the cy
by waterhouse 16y ago
Beginning of an outline of a proof...
arc> (dedup:mapn [mod-expt 2 _ 100] 2 100)
(4 8 16 32 64 28 56 12 24 48 96 92 84 68 36 72 44 88 76 52)
That's the cycle of powers of 2 mod 100. (I removed the beginning 1 and 2, which don't repeat.) The first two numbers will show up as 04 and 08 in our number (except when the number is 4 or 8). Thus, there's always a 0 when n is 2 or 3 mod 20. (Note that there are 20 numbers up there.)
arc> (no:prn:dedup:mapn [string:num->digs (mod-expt 2 _ 1000) 10 3] 3 1000)
(008 016 032 064 128 256 512 024 048 096 192 384 768 536 072 144 288 576 152 304
608 216 432 864 728 456 912 824 648 296 592 184 368 736 472 944 888 776 552 104
208 416 832 664 328 656 312 624 248 496 992 984 968 936 872 744 488 976 952 904
808 616 232 464 928 856 712 424 848 696 392 784 568 136 272 544 088 176 352 704
408 816 632 264 528 056 112 224 448 896 792 584 168 336 672 344 688 376 752 504)
That's the cycle of powers of 2 mod 1000, starting with n=3. There are 100 numbers. (Incidentally, the Euler-Fermat theorem and some thinking can tell you that the cycle of powers of 2 mod 10^k will have length that divides phi(5^k), which is 4 * 5^(k-1), which is 4, 20, 100, 500, etc.) I'll make my computer figure out which numbers contain 0.
arc> (let u (dedup:mapn [string:num->digs (mod-expt 2 _ 1000) 10 3] 3 1000) (keep [pos #\0 u._] (range 0 dec:len.u)))
(0 1 2 3 7 8 9 14 19 20 39 40 59 60 76 79 80 85 99)
Which is 19 out of the 100 different things mod 1000. Now let's write a function to deal with 10^k.
(def ass (k)
(withs (pt (expt 10 k)
u (dedup:mapn [string:num->digs (mod-expt 2 _ pt) 10 k]
k (+ k (* 4 (expt 5 dec.k)))))
(list (count [pos #\0 _] u)
len.u)))
To explain the above code: I let "pt" = 10^k, then I take the numbers from k to k + 4 * 5^(k-1), find 2^n (mod pt), write out its digits in base 10 (and force there to be k digits, by appending 0's to the front if necessary), put the digits together into a string, make a list of all these resulting strings, remove duplicates just to be sure, and give the resulting list the name "u"; then I return a list of two numbers, the number of strings in the list that contain 0, and the total number of strings in the list. From what we've seen above, we'd expect (ass 2) to return (2 20), and (ass 3) to return (19 100).
arc> ass.2
(2 20)
arc> ass.3
(19 100)
That's a good sign. Now let's proceed to higher numbers. I'll make it print out the resources it's using, too.
arc> time:ass.4
time: 30 gc: 0 mem: 2458488
(136 500)
arc> time:ass.5
time: 338 gc: 169 mem: -21400960
(862 2500)
arc> time:ass.6
time: 905 gc: 141 mem: -2376232
(5129 12500)
arc> time:ass.7
time: 4333 gc: 227 mem: 43046240
(29330 62500)
arc> time:ass.8
time: 28885 gc: 1797 mem: 74515640
(163232 312500)
Well, we've passed the halfway mark, but my computer is feeling the pressure. If you rewrote this in C or something, you might be able to go up a few numbers higher, but probably not much. (Hmm, actually, I'm kind of repeating a bunch of work: I already know that "2 and 3 mod 20" numbers always have a 0, and similar for "3 4 5 6 10 ... mod 100 [add 3 to my third list of numbers]". However, if I ignored those, that would only cut out half the work for k=8. But maybe a lot more will get cut out in higher numbers, and the number of things to deal with will become manageable?)
Well, in principle at least, this could be solved by computer.
Edit: Hmm, qntm seems to have said much of this already. Well, at least I have done some grunt work to illustrate his arguments.
- impendia 16y ago+1. At first I thought that none of these statements could even remotely be proved, but I've changed my mind. I totally buy this. In particular, it looks like this would prove "Every sufficiently large power of 2 contains at least k zeroes", for any value of k. The computational time would probably be prohibitive, but this should definitely work in principle. As a working analytic number theorist, I suspect the asymptotic formula is out of reach, for similar reasons to why you can't count twin primes. I'd be very pleased if someone persuaded me I'm wrong. But, please, none of this mumbo-jumbo about "higher order Fourier analysis". Gowers et al. developed it to find progressions in arithmetic sequences, which is not related to the present problem as far as I can see.
- Someone 16y agoit looks like this would prove "Every sufficiently large power of 2 contains at least k zeroes", for any value of k. The computational time would probably be prohibitive, but this should definitely work in principle. Only when you accept constructive proofs that do not say anything about their running time and that may not even halt. I suspect the asymptotic formula is out of reach, for similar reasons to why you can't count twin primes. I am not aware of any result on the _inherent_ difficulty of counting twin primes. Are you hinting at one? If so, can you give a reference?
- impendia 16y agoBy "in principle" I am excluding any consideration of running time, or computing resources. For example, if k = 10, perhaps you would need a computer with 10^10000 bytes of RAM working for an equal number of years. It's a finite computation. ;) "may not even halt" corresponds to my "it looks like". Such algorithms not working would be equivalent to me and the parent commenter being wrong -- which is not out of the question. Probabilistically, such an algorithm should work (I think -- have not checked the details), so it ought to work unless there is some unforeseen reason why it wouldn't. A "conspiracy" against this happening, if you will. As far as the difficulty in counting twin primes -- well, to give an easier example, look at Cojocaru and Murty's book on sieve methods and read about the sieve of Eratosthenes-Legendre. You know that 1/2 of numbers are even, 2/3 aren't divisible by 3, 4/5 aren't divisible by 5, etc., so the proportion of numbers that are prime is equal to (1/2)(2/3)(4/5)(6/7)..., which you can show with a little bit of effort is equal to 0. With some work, you can turn this into a proof. In theory, you can estimate the number of primes < X, as a function of X. This estimate would be roughly along the lines of the original post. But as Cojocaru and Murty (among others) point out, the error terms get bad quickly. This type of phenomenon is extremely common in analytic number theory. In the case of prime counting, you can get better results by other methods, most prominently the Riemann zeta function. But even then you can only get the best results if you prove the Riemann Hypothesis. Million dollar bounty out on that one.