I'm not doing updates on fatou.gp until after I finish a rigorous proof of convergence proving a simplified version of fatou.gp for base e converges to Kneser's slog.

The upper limit for tetration bases supported is somewhere around base(35000).

pentinit(1.6); ipent(3) is a non-trivial problem since there are three different real valued fixed points for tet_b=1.6. See this thread about the tetration base with an upper parabolic fixed point (b~= 1.6353). For pentation, with bases smaller than this, the result is ambiguous since there are now three real fixed points. For pentation fatou.gp arbitrarily uses the lower fixed point, which is all we have for larger bases. But it is arbitrary since there is no uniqueness criterion for pentation analogous to the uniqueness criterion for Kneser's tetration. For pent(1.6); we see that sexp_1.6(-1.62779274874299)=-1.62779274874299 which is the lower fixed point, and is where the Schroeder equation for pentation is centered. But if we start at z=3, and iterate z<=sexp_1.6(z) then we get to the 1st upper fixed point= 2.26438440348116, and if we start at z=3 and iterate z<=slog(z), then we get to the 2nd upper fixed point=4.7558078933440; neither of which is the desired lower fixed point. The tetration b=1.6 image below shows the two additional upper fixed points that make finding ipent(3) difficult when using the lower fixed point's Schroder equation for pentation.

Hopefully that explains why I wouldn't update the fatou.gp code for pentinit(1.6). This is especially true given that my current primary focus is on a tetration proof.

07/03/2022, 01:55 AM (This post was last modified: 12/15/2022, 04:53 AM by Catullus.)

If I try to make fatou.gp generate tetration at base e^-e, there are spikes. Why?
Is it an error with the program?
Is the analytic continuation of the Kneser method spikey at that base?
There should be a way to see .svg files attached to posts on this forum without having to download them.
Here are graphs of the real and imaginary parts of according to fatou.gp. Where the red graph represents the real part, and the green graph represents the imaginary part:

Hey, Catullus. This is common dealing with the neutral fixed points. There are erroneous codes which get far more sensitive near the boundary. Fatou.gp, it is not designed for the boundary values. Kneser, itself, is not designed for the boundary values. It is much more conducive to outside of the Shell-Thron region. For boundary values like \(e^{-e}\), personally I would use the beta method, though it adds a caveat that you have to introduce a period term. So there's a multiplier \(\lambda\), so that your tetration \(F\) is \(2 \pi i/\lambda\) periodic. But regardless, it constructs the abel function very quickly and effectively. And avoids any Kneser protocol, which is designed to fail at neutral values.

07/03/2022, 08:56 AM (This post was last modified: 12/15/2022, 04:56 AM by Catullus.)

If I do sexpinit(Pi^(1/Pi)), imag(sexp(x)) looks spikey.
If I increase the precision from \ps 21 to \ps 38, when I plot the imaginary part, it looks like a straight line at zero. (It also happened for higher precisions I tried.) Implying that it is real valued, but the analytic continuation of the Kneser method is not real valued at the pith root of pi. And then, when I tried to plot sexp(x) it said "*** incorrect type in gtodouble [t_REAL expected] (t_COMPLEX).".
Why was that happening?
Here is a graph of according to fatou.gp at \ps 21:

07/04/2022, 11:28 PM (This post was last modified: 07/04/2022, 11:29 PM by JmsNxn.)

(07/03/2022, 08:56 AM)Catullus Wrote: If I do sexpinit(Pi^(1/Pi)), imag(sexp(x)) looks spikey.
If I increase the precision from \ps 21 to \ps 38, when I plot the imaginary part, it looks like a straight line at zero. (It also happened for higher precisions I tried.) Implying that it is real valued, but the analytic continuation of the Kneser method is not real valued at the pith root of pi. And then, when I tried to plot sexp(x) it said "*** incorrect type in gtodouble [t_REAL expected] (t_COMPLEX).".
Why was that happening?
Here is a graph of , according to fatou.gp at \ps 21:

Those are simply artifacts. They are completely inconsequential because it's still 0 to 21 digits. This is common with any tetration calculator. I'd say that's pretty good considering it's zero to 29 digits for all those errors.

Don't worry about it. To avoid the error you are getting, try plotting real(sexp(x)), it'll delete what is essentially just some noise.

07/05/2022, 01:31 AM (This post was last modified: 12/15/2022, 04:58 AM by Catullus.)

(07/04/2022, 11:28 PM)JmsNxn Wrote:

(07/03/2022, 08:56 AM)Catullus Wrote: If I do sexpinit(Pi^(1/Pi)), imag(sexp(x)) looks spikey.
If I increase the precision from \ps 21 to \ps 38, when I plot the imaginary part, it looks like a straight line at zero. (It also happened for higher precisions I tried.) Implying that it is real valued, but the analytic continuation of the Kneser method is not real valued at the pith root of pi. And then, when I tried to plot sexp(x) it said "*** incorrect type in gtodouble [t_REAL expected] (t_COMPLEX).".
Why was that happening?
Here is a graph of , according to fatou.gp at \ps 21:

Those are simply artifacts. They are completely inconsequential because it's still 0 to 21 digits. This is common with any tetration calculator. I'd say that's pretty good considering it's zero to 29 digits for all those errors.

Don't worry about it. To avoid the error you are getting, try plotting real(sexp(x)), it'll delete what is essentially just some noise.

But, when I increase the precision from \ps 21 to \ps 38‚ the imaginary part of sexp(x) looks like a straight line at zero. But the imaginary part is supposed to be wavy‚ like a decreasing sine wave, and zero at integers greater than negative two. That is how the analytic continuation of the Kneser method is below eta.

07/05/2022, 01:36 AM (This post was last modified: 07/05/2022, 01:37 AM by JmsNxn.)

(07/05/2022, 01:31 AM)Catullus Wrote:

(07/04/2022, 11:28 PM)JmsNxn Wrote:

(07/03/2022, 08:56 AM)Catullus Wrote: If I do sexpinit(Pi^(1/Pi)), imag(sexp(x)) looks spikey.
If I increase the precision from \ps 21 to \ps 38, when I plot the imaginary part, it looks like a straight line at zero. (It also happened for higher precisions I tried.) Implying that it is real valued, but the analytic continuation of the Kneser method is not real valued at the pith root of pi. And then, when I tried to plot sexp(x) it said "*** incorrect type in gtodouble [t_REAL expected] (t_COMPLEX).".
Why was that happening?
Here is a graph of , according to fatou.gp at \ps 21:

Those are simply artifacts. They are completely inconsequential because it's still 0 to 21 digits. This is common with any tetration calculator. I'd say that's pretty good considering it's zero to 29 digits for all those errors.

Don't worry about it. To avoid the error you are getting, try plotting real(sexp(x)), it'll delete what is essentially just some noise.

But when I increase the precision from \ps 21 to \ps 38‚ the imaginary part of sexp(x) looks like a straight line at zero. But the imaginary part is soppost to be wavy‚ like a decreasing sine wave and zero at integers greater than negative three. That is how the analytic continuation of the Kneser method is below eta.

I cannot speak for Sheldon, but this program is intended for outside of Shell-Thron. On the interior, I believe that Kneser, is not Kneser, as Sheldon programs it. So it runs a more traditional algorithm. I could be wrong in the exact information of this. But \(\sqrt{2}\) produces the standard Shroder iteration with less than desirable accuracy.

This program does not produce Kneser as a mathematical object within the interior. I could be off a bit, but this is what I remember from my conversations with Sheldon.

07/05/2022, 08:20 AM (This post was last modified: 07/05/2022, 09:52 AM by Catullus.)

(07/05/2022, 01:36 AM)JmsNxn Wrote: I cannot speak for Sheldon, but this program is intended for outside of Shell-Thron. On the interior, I believe that Kneser, is not Kneser, as Sheldon programs it. So it runs a more traditional algorithm. I could be wrong in the exact information of this. But \(\sqrt{2}\) produces the standard Shroder iteration with less than desirable accuracy.

This program does not produce Kneser as a mathematical object within the interior. I could be off a bit, but this is what I remember from my conversations with Sheldon.

Didn't Gottfried use fatou.gp to generate the analytic continuation of the Kneser method at base i to make this picture: ?