I wonder if the double dabble binary to decimal algorithm could be modified to check this relatively efficiently?<p><a href="https://en.wikipedia.org/wiki/Double_dabble" rel="nofollow">https://en.wikipedia.org/wiki/Double_dabble</a><p>for 2^n only zeroes are shifted in, to all eternity. thus the lowest digits go through a fixed cycle.<p>as the top but is shifted to the left in each shift+add-threes-where-needed cycle, and leaves "it's" bcd digit after four such cycles, I intuit the next bcd byte will also switch to some cycle, as it's 'input' is boringly deterministic: all zeroes for the lowest digit, leading to 1, 2, 4, 8 (1)6, (1)2, 4, 8, (1)6, (1)2, ... so 0000(1100)* is shifted in to the tens digit.<p>that gives 0,0,0,0,
0+1, 2+1, 6, (1)2,
4+1, (1)0+1, 2, 4,
8+1, (1)8+1, (1)8, (1)6,
(1)2+1, 6+1, (1)4, 8,
(1)6+1, (1)4+1, (1)0, 0,
0+1, 2+1, ... for the tens digit. which has a period of 20 ... with a shift to hundreds pattern of 0000(00010100011110101110)* and an odd odd even even rhythm on the tens digit.<p>noice.<p>some number nerds will for sure figure or know ways to spin this on for the hundreds digit. and determine the periodicity of having all the lowest n digits even. or the loss of that periodicity... because maybe just maybe this spins into some wheel where one of the digits foo to bar always is odd. and then you can stop searching...<p>but what do I know.<p>I just Dunning-Kruger an intuition that the "double dabble" bin2bcd _may_ be useful in this :-D