Hmm, I get that the last 4 digits of the Moser are 1056.? Can you post your method of derivation, Ikosarakt1?Deedlit11 (talk) 00:51, November 23, 2012 (UTC)

I compute the last 4 digits of 2 in next -gon (expect 2[4], this is obvious that 4^4 = 256) by following method: raise the last 4 digits into power of itself, take the last digits 4 and add 2 to 4th digit:

2[3] = 4
2[4] = 256
2[5] = ...2656 (since 256^256 = ...0656, 2[5] = ...2656)
2[6] = ...9056 (since 2656^2656 = ...7056, 2[6] = ...9056)
2[7] = ...9456
2[8] = ...3856
2[9] = ...2256
2[10] = ...4656

Then I notice that 2[5] = ...2656, 2[10] = ...4656, this leads me to cycle:

2[15] = ...6656
2[20] = ...8656
2[25] = ...0656
2[30] = ...2656

Again, 2[5] = ...2656, 2[30] = ...2656, 2[n] and 2[n+25] have same last 4 digits:

2[55] = ...2656
2[56] = ...9056
2[81] = ...9056
2[106] = ...9056
2[131] = ...9056
2[156] = ...9056

Since no matter how big number of digits before ...56, 2[...56] = ...9056, Moser = 2[2[5]], but 2[5] ends at ...56, then Moser = 2[...56] = ...9056.


Unfortunately, I do not see how your method works;  it does not seem to me that taking the last four digits to its own power mod 10000 and then adding 2 to the first digit should get you the next number in the sequence.

Here is how i did it:


Let M(a, b, c) be a inside c b-gons.

First consider M(2, 3, n) mod 10000: The first 28 values are

{4, 256, 656, 5056, 3456, 5856, 2256, 2656, 7056, 5456, 7856, 4256, \
4656, 9056, 7456, 9856, 6256, 6656, 1056, 9456, 1856, 8256, 8656, \
3056, 1456, 3856, 256, 656}

We see that the pattern repeats every 25 entries.  So for an arbitrary M(2, b, c), it is enough to know the number of times the triangle operator is applied mod 25.

Next consider M(2, 4, n) mod 10000.  We want to know the number of times the triangle operator is applied mod 25.  The first square turns into 2 triangles.  The next square turns into M(2, 4, 1) triangles.  The next square turns into M(2, 4, 2) triangles, all the way up to M(2, 4, n-1).  So the number of triangle operators applied mod 25 is:

2 + M(2, 4, 1) + M(2, 4, 2) + ... + M(2, 4, n-1) mod 25

= 2 + 6 + 6 + ... + 6 mod 25 = 2 + 6(n-1) mod 25 = 6n-4 mod 25.

So to find M(2, 4, n) mod 10000, we just compute 6n-4 mod 25, and find that place in the above calculated sequence for M(2, 3, n).

Now we consider M(2, 5, n) mod 10000.  By the same argument, the number of squares applied when evaluating M(2, 5, n) mod 10000 is

2 + M(2, 5, 1) + M(2, 5, 2) + ... + M(2, 5, n-1) mod 25

= 2 + 6 + 6 + ... + 6 mod 25 = 2 + 6(n-1) mod 25 = 6n-4 mod 25.

So M(2, 5, n) mod 10000 is the same as M(2, 4, 6n-4) mod 10000, which is the same as M(2, 3, 6(6n-4) - 4) = M(2, 3, 36n - 28).

So for each level of polygon we iterate 6n-4 mod 25.  A little calculation shows that the iterations of 6n-4 mod 25 repeat with period 25.  So M(a, b+25n, c) mod 10000 = M(a, b, c) mod 10000.

Since M(2, 5, 1) = 6 mod 25, Moser mod 10000 = M(2, M(2, 5, 1), 1) mod 10000 = M(2, 6, 1) mod 10000

= M(2, 5, 2) mod 10000 = M(2, 4, 8) mod 10000 = M(2, 3, 44) mod 10000 = M(2,3, 19) mod 10000

= 1056 mod 10000.

I'm pretty confident about this, so I'm going to amend the page.

Deedlit11 (talk) 03:50, December 1, 2012 (UTC)

Bounds

Any bounds for this guy in arrow notation or BEAF? FB100Ztalkcontribs 20:48, January 9, 2013 (UTC)

Polygon notation seems to be as powerful as arrow notation, where number of angles corresponds to number of arrows, number of polygons to polyponent, and number in the centre to base. Here is my accurate bounds:

\( a \uparrow^{c-1} b+1 < a[c]_b < a \uparrow^{c-1} b+2 \)

I tested these bounds, and it really works, for example, for Mega:

\( 2[5] = 2[4]_2 = 256[3]_{256} \)

\( 256 \uparrow\uparrow 257 < 256[3]_{256} < 256 \uparrow\uparrow 258 \)

Thus for Moser:

\( 2[mega] = 2[mega-1]_2 \)

\( 2 \uparrow^{mega-2} 3 < Moser's number < 2 \uparrow^{mega-2} 4 \) Ikosarakt1 (talk) 10:33, January 10, 2013 (UTC)

More last digits?

On the page it is given that the last 4 digits of Moser are ...1056, but is it possible to calculate more? Allam948736 (talk) 01:26, October 17, 2019 (UTC)


I obtained ...80,301,056 for the last 8 digits, but I'm not quite sure if that's correct or not. Allam948736 (talk) 18:10, January 13, 2020 (UTC)

If you want a feedback on your result, how about showing the precise method which you used?
p-adic 22:51, January 13, 2020 (UTC)
I simply observed that 2[4] is just 256, 2[5] ends in ...60,742,656, 2[6] ends in ...79,341,056 (let's not get started on how I calculated that), and so on. For 7 digits I found the last digits of 2[7], 2[8], 2[9], and 2[10] on this Mathematics StackExchange thread , and analyzed the last digits of successive members of the sequence. For instance, each time we increment the number of sides in the polygon by 1, we add 400 to the last 3 digits, and for 4 digits, we add 8400, then 4400, then 400, then 6400, and finally 2400 before repeating. Also, each time we add 5 sides starting with 2[6], we add 32000 to the last 5 digits. Explaining this for more digits, however, would take a whole paragraph by itself. Allam948736 (talk) 01:18, January 14, 2020 (UTC)
Even if you found patterns of last digits for sufficiently small values, it does not imply that it holds forever. Is there any theoretical background that your method (restricted to last 4 digits) actually works, i.e. the last 4 digits is cyclic of period 5? It might be obvious for you, but I am too lazy to verify the statement by myself.
p-adic 01:45, January 14, 2020 (UTC)
2[4] is just 256, 2[5] ends in 2656, 2[6] ends in 1056, 2[7] ends in 5456, 2[8] ends in 5856, 2[9] ends in 8256, and 2[10] ends in 4656. To get from 2[4] to 2[5] we add 2400, then we add 8400 to obtain the last 4 digits of 2[6], 4400 to obtain the last 4 digits of 2[7], 400 to obtain the last 4 digits of 2[8], 6400 to obtain the last 4 digits of 2[9], and we add 2400 once again to obtain the last 4 digits of 2[10]. Using this, Moser = ..................1056. As for why it works, though, I'm still not quite sure. Allam948736 (talk) 02:04, January 14, 2020 (UTC) 
If you do not have a theoretic reason for last digits of larger values, then it should not be written as a fact in the article. If you want to add it to the article, then it is good to clarify something like "Allam conjectures the last 8 digits of Moser are ... through the observation of last 8 digits of lower values".
p-adic 03:09, January 14, 2020 (UTC)


So I tried a different method: take the last 6 digits of Mega, raise that to the power of itself, then add 544000 to the last 6 digits of that number to get the last 6 digits of 2[6] (which are indeed ...341056), then take the last 6 digits of 2[6], raise to the power of itself, then add 496000 to obtain the last 6 digits of 2[7], then raise that to the power of itself and add 768000 to obtain last 6 digits of 2[8] (...305856). To obtain last 6 digits of 2[9] you raise this to the power of itself and add 760000. After that, you would raise that to the power of itself and then add 872000. Based on this, the next differences after this should be 504000, (0)56000, 928000, and 520000. This method agrees with the results I obtained using the other method, thus using this, Moser = ......301056. Allam948736 (talk) 01:07, January 15, 2020 (UTC)
Could you understand that any "method" compatible with lower values without theoretic background should not written as a fact in the article...? The compatibility does not imply the correctness. You have only to write a proof in order to verify the correctness instead of to observe pattern-matching. I am afraid that your other results added to articles are based on similar pattern-matching without theoretic background...
p-adic 01:13, January 15, 2020 (UTC)


My results for the last digits of 3[5], 4[5], 5[5], 6[5], 7[5], 8[5], and 9[5] are based on actual computation. In the case of Moser, however, the number of iterations that would be required to compute the last digits directly is itself extremely large, so we have to rely on patterns in smaller values. The last 3 digits always increasing by 400 can be explained by the fact that 256 ends in 56 and 256[3] ends in 656, 656[3] ends in 056, 56[3] ends in 456, 456[3] ends in 856, and 856[3] ends in 256. When we apply the square operator it is equivalent to applying the triangle operator only once since any number ending in ...56 is 1 mod 5. This means that applying the pentagon operator is also equivalent to one triangle since it is equivalent to one square, and the same goes for all higher operators.  Allam948736 (talk) 01:52, January 15, 2020 (UTC)
> so we have to rely on patterns in smaller values.
No. We have to rely on proofs. Pattern-matching is not reliable and is not reasonable. Do you forget that your statements on last digits of tetrations without proofs were wrong?
> This means that applying the pentagon operator is also equivalent to one triangle since it is equivalent to one square, and the same goes for all higher operators.
Are you talking about the last 1-digit? Do you forget that the simple iteration of "modular exponential" modulo 5 does not work in general? (Also, "it is compatible with any small values which I checked" makes no sense here.) Anyway, since you seem to have no evidence (no, it is not the compatibility with small values), your statements are not approopriate for the main article. This is the case if you show us any other compatible results of small values.
p-adic 05:29, January 15, 2020 (UTC)


I was talking specifically about the last 3 digits (explaining it for more digits would be quite tricky though). For 4 digits, you would have to apply 6 triangles to 256, then 11 triangles to 2656, 16 triangles to 1056, and so on. Allam948736 (talk) 16:24, January 15, 2020 (UTC)
It makes sense. Anyway, we need a theoretic reasoning.
p-adic 23:19, January 15, 2020 (UTC)
Community content is available under CC-BY-SA unless otherwise noted.