Computing Integer Tetrations

[Catullus]

How does one efficiently compute integer tetrations? Like how would one efficiently compute η^^16,384 without having to do 16,383 exponentiations?

[JmsNxn]

How does one efficiently compute integer tetrations? Like how would one efficiently compute η^^16384, without having to do 16383 exponentiations?

Hey Catullus!

This is actually a very difficult and deep question. I, myself, have my own way of doing this--and there are countless papers on how do it.

Integer tetrations are problematic, only in that, every coding method must produce integer tetrations. So that, every solution to \(\eta\uparrow\uparrow z\) must produce integer tetrations.

Personally, I don't think anyone knows "the fastest way", but I would wager a guess, for \(1 \le b \le \eta\) or any \(b\) in the Shell thron region, the Schroder method can be massaged into the fastest.

If that doesn't concern you, which is fastest, there's always the beta method. The beta method is especially good for \(b\) in the Shell-thron region, it can be slow elsewhere. Outside shell thron, the fastest way is to use Sheldon's fatou.gp. And this is a little tricky to learn how to use; there's a learning curve; but it's unreasonably fast.

So, I'd suggest my own beta.gp for within the Shell thron region (so for your example of \(\eta\)), and Sheldon's fatou.gp anywhere else. Note, that it will use Kneser's solution as a derivation. My solution uses infinite compositions. Neither uses Schroder's iteration. There's definitely a learning curve to both programs, but Sheldon's is by far the better program, albeit harder to use at first. But for Shell-Thron, my program is a tad more versatile, as it allows you to create different holomorphic solutions to tetration. And for integer tetration, sheldon's I feel is a tad slower for the shell thron region.

That being said, you can run either program for integer tetrations.

My beta program is here:

https://math.eretrandre.org/tetrationfor...p?tid=1379

And Sheldon's fatou.gp is here:

https://math.eretrandre.org/tetrationfor...p?tid=1017



Note that both are written in pari-gp. This is sort of the standard on this forum. Pari GP is a C based programming language, which acts as a raw symbolic calculator. So you'll have to aquaint yourself to it to use these programs. I understand your struggle of figuring out how to use these programs, I'd suggest Sheldon's fatou.gp if you don't care too much. The documentation is much better for it. But running \(\sqrt{2}\uparrow\uparrow z\) will be more inaccurate (Kneser's solution isn't designed for this). Integer tetrations shouldn't be a problem though, as long as you aren't worried about exact accuracy.

Message me if you need help setting up pari, and understanding how to use either program to do integer tetrations. Happy to help .

[Catullus]

How does one efficiently compute integer tetrations? Like how would one efficiently compute η^^16384, without having to do 16383 exponentiations?

Hey Catullus!

This is actually a very difficult and deep question. I, myself, have my own way of doing this--and there are countless papers on how do it.

Integer tetrations are problematic, only in that, every coding method must produce integer tetrations. So that, every solution to \(\eta\uparrow\uparrow z\) must produce integer tetrations.

Personally, I don't think anyone knows "the fastest way", but I would wager a guess, for \(1 \le b \le \eta\) or any \(b\) in the Shell thron region, the Schroder method can be massaged into the fastest.

If that doesn't concern you, which is fastest, there's always the beta method. The beta method is especially good for \(b\) in the Shell-thron region, it can be slow elsewhere. Outside shell thron, the fastest way is to use Sheldon's fatou.gp. And this is a little tricky to learn how to use; there's a learning curve; but it's unreasonably fast.

So, I'd suggest my own beta.gp for within the Shell thron region (so for your example of \(\eta\)), and Sheldon's fatou.gp anywhere else. Note, that it will use Kneser's solution as a derivation. My solution uses infinite compositions. Neither uses Schroder's iteration. There's definitely a learning curve to both programs, but Sheldon's is by far the better program, albeit harder to use at first. But for Shell-Thron, my program is a tad more versatile, as it allows you to create different holomorphic solutions to tetration. And for integer tetration, sheldon's I feel is a tad slower for the shell thron region.

That being said, you can run either program for integer tetrations.

My beta program is here:

https://math.eretrandre.org/tetrationfor...p?tid=1379

And Sheldon's fatou.gp is here:

https://math.eretrandre.org/tetrationfor...p?tid=1017



Note that both are written in pari-gp. This is sort of the standard on this forum. Pari GP is a C based programming language, which acts as a raw symbolic calculator. So you'll have to aquaint yourself to it to use these programs. I understand your struggle of figuring out how to use these programs, I'd suggest Sheldon's fatou.gp if you don't care too much. The documentation is much better for it. But running \(\sqrt{2}\uparrow\uparrow z\) will be more inaccurate (Kneser's solution isn't designed for this). Integer tetrations shouldn't be a problem though, as long as you aren't worried about exact accuracy.

Message me if you need help setting up pari, and understanding how to use either program to do integer tetrations. Happy to help .

Thank you for helping. What about using kneser.gp?

[JmsNxn]

Ya, I'd suggest fatou.gp all the way down the line. The beta.gp is really only better for making modified tetrations on Shell-Thron.

Kneser.gp is an older version of fatou.gp if I'm correct. Definitely use fatou.gp

[Catullus]

Kneser.gp is an older version of fatou.gp if I'm correct. Definitely use fatou.gp

But kneser.gp produces more digits of precision than fatou.gp. With default settings on both.

[JmsNxn]

Kneser.gp is an older version of fatou.gp if I'm correct. Definitely use fatou.gp

But kneser.gp produces more digits of precision than fatou.gp. With default settings on both.

OH shit, I've never looked at this program before. It was published later. You're probably right. Now that I think about it, I think Sheldon explained a speed up program he wrote, didn't realize this was it. I apologize. You're probably right.