[nneonneo]

Fun fact: 2^133477987019 is the smallest power of two that ends with 40 even digits. In fact, it ends with 46 even digits - which is surprising, given that it is significantly smaller than 2^(2^46). The last 50 digits of this number are ...32070644226208822284248862288402404246620406284288. This number has over 40 billion digits, though, so it seems kind of unlikely that we will ever find another number where all the digits are even. The relevant OEIS sequence is here: https://oeis.org/A096549

Context: I wrote a search program that is substantially faster - it takes just a few minutes to get up to 2^(10^13), although my laptop's limited memory is starting to be a problem (my intermediate result file is already nearly 1GB in size). Unfortunately, it seems there are no results up to 2^15258789062500, which is a 4.5-trillion digit number.

[FartyMcFarter]

I think you can calculate "2^X mod (10^N)" where N is the number of digits using a modular exponentiation algorithm.

This would avoid using a lot of memory, and it would also be faster.

[nneonneo]

I am already doing that (thanks to `pow(x, y, z)` in Python). The numbers I'm working with would have trillions of digits were it not for this trick - way more than 1GB. 1GB is what I use to store all of the candidates, in an inefficient JSON format.

[shrx]

Is your algorithm published somewhere?

[nneonneo]

I literally just invented it, so it's not published yet, although I'll probably throw it up on GitHub at some point. It matches all published results up to an exponent of 3 billion or so, so I'm quite confident it's correct.

The short explanation is that 2^x mod 10^k will repeat with a cycle length of 5^(k-1)*4. This is easily obtained from Euler's phi formula on 2^x mod 5^k, plus the fact that 2^x === 0 mod 2^k for all x >= k. So, after the k'th term, the rest will repeat with a particular cycle period. We'll manually test all of the 2^x for x < k (there aren't many) and then rely on the cycles to test all of the larger powers.

The algorithm itself is a kind of sieving + lifting procedure: it inductively identifies all of the candidate exponents mod 5^(k-1)*4 which yield numbers with k trailing even digits (i.e. all even digits mod 10^k). Each such exponent will yield 5 possible exponents mod 10^(k+1) via a lifting procedure, which we can test; on average, half of these will have a top digit that is even and is therefore a candidate for the next power of 10 (10^(k+1)). Therefore, on average, we grow our candidate list by a factor of 2.5 per added digit - thus, for each 10^k, we test O(2.5^k) candidates (approximately 1.6*2.5^k, experimentally). This isn't too bad - at mod 10^19, we test only 55097940 candidates, representing every exponent below 5^18*4 = 15258789062500.

My rather hasty prototype is actually implemented in Python - not a language you want to do tons of arithmetic in - but it's still fast enough to chew through all those candidates in ~20 minutes on a single core. Obviously, there's ample room to make this faster; I figure a good, parallelized native (C/C++/Rust etc.) implementation could easily be 100x faster.

[eru]

> My rather hasty prototype is actually implemented in Python - not a language you want to do tons of arithmetic in [...]

It might actually not be too bad? The actual big integer arithmetic is written in some fast language, and Python is just the glue holding everything together.

[saagarjha]

I don't think Python has a particularly optimized bignum implementation.

[nneonneo]

Additionally, it requires allocating memory for every operation. With a mutable bigint type, or fixed-size large integers (e.g. uint256) we could skip a lot of allocation overhead. I have previously prototyped big integer algorithms in Python, and when rewriting to Rust I have gotten massive speedups - there are just so many more opportunities to optimize in Rust/C/C++ than in Python.

[eru]

Well, it's still better than trying to implement bignums in Python itself on top of limited precision integers.

I'm not even sure whether the prototype in question here uses bignums. Perhaps they use numpy in some clever way (which would probably be a better illustration of my thesis). Or perhaps it's fast enough as it is?

[ted_dunning]

That is basically the same algorithm I used. The sieve I used was only mod 10^15 but it sufficed to give the results at 10^13 in a few seconds and 10^15 in a few hours.

As mentioned in another comment, the code is at: https://github.com/tdunning/EvenDigits