complex base tetration program

[Gottfried]

In the case at hand, the other fixed point, for the lower half of the complex plane for sexp(z), is -1.862-0.411i, which Gottfried has listed strangely as 3-periodic, where as it is a simple repelling fixed point for . (...)

Upps, that was an error in the manual transfer of the values into the table, sorry. I've updated the picture.

Gottfried

[Gottfried]

Hi Sheldon -

inspired by the bugs, rooted in interferences between the procedures in fatou.gp and my std-user-library I was also reviewing the older tetcomplex.gp procedure which you've posted earlier (and which worked in my environment with very little renaming-conventions), and did also some minor edits for numerical improvements (replaced "eval"-procedures by "subst") and deleted all "kill(x)"-calls.


Using the base I could nicely reproduce the problem in MSE: does exist and then what is in

By some other idea I investigated the behave near above the real axis, and specifically I looked at the point and found, that the required height to iterate from to is nearly , so



That this is very near suggests, that here equality is intended (and it is also different from the Schröder-method). However, the error is in the near of 0.003 which looks large in comparision to the numerical accuracy for other computations (20 to 30 digits correct by my initialization) .

Could that result be improved by some finetuning? (Or did I speculate wrongly?)

Gottfried

[sheldonison]

By some other idea I investigated the behave near above the real axis, and specifically I looked at the point and found, that the required height to iterate from to is nearly , so



That this is very near suggests, that here equality is intended....

Gottfried,

You're using a real base>exp(1/e). Either base(2) or base(e), so you don't really need the complex base support in tetcomplex. Kneser.gp would work just fine, and as you noted, tetcomplex won't work with the latest versions of pari-gp.

For any real valued sexp base as imag(z) increases, sexp(z) will go to the fixed point, since the Kneser tetration function is a 1-cyclic mapping of S(z) where S(z) is the Schröder solution superfunction from the complex fixed point. By definition, . In the upper half of the complex plane, we use and in the lower half of the complex plane we use generated from the complex conjugate fixed point.





The solution in the upper half of the complex plane approaches as increases. This is because the periodic terms in the 1-cyclic mapping quickly decay to zero as imag(z) increases leaving only the constant term of k. Try plugging in z=2*I into this equation for theta, to see how quickly the periodic terms in decay.



The functions are also periodic with a different period that decays more slowly. For base2 the Su(z) Schröder solution superfunction has a period of 5.584 + 1.0542*I, and Su(z) decays to the fixed point as increases, but the periodic terms in Su(z) decay much more slowly than the function.

At the real axis has a really complicated singularity at integer values of z, since the Schröder superfunction solution never takes on the values of 0 anywhere in the complex plane, and yet sexp(-1)=0. So is only used in the upper half of the complex plane; and its complex conjugate is used in the lower half of the complex plane.

So sexp_2(2*Pi*I) = 0.827783486030388 + 1.56642681578434*I; and the fixed point is 0.824678546142074 + 1.56743212384965*I.
abs(sexp_2(2*Pi*I)-L)=0.00326
abs(sexp_2(10*I)-L)=0.0000572
abs(sexp_2(20*I)-L)=1.101E-9
abs(sexp_2(30*I)-L)=2.105E-14
I hope this helps.

[Gottfried]

So sexp_2(2*Pi*I) = 0.827783486030388 + 1.56642681578434*I; and the fixed point is 0.824678546142074 + 1.56743212384965*I.
abs(sexp_2(2*Pi*I)-L)=0.00326
abs(sexp_2(10*I)-L)=0.0000572
abs(sexp_2(20*I)-L)=1.101E-9
abs(sexp_2(30*I)-L)=2.105E-14
I hope this helps.

Hi Sheldon -

yes, this helps, thank you. My speculation was unfounded.

Gottfried

<hr>
P.s. I have still to use Pari/GP in the 2.2.11 version because in the next version they removed the feature, switched on be option -emacs, to give a textual "prompt" after each output (*) when Pari/GP was used in as subprocess in a GUI. I could use that "prompt" to detect end-of-answer and construct the conversation with the GUI around this. I don't know why they did this and after a query at Karim Belabas, I'm left with little hope that this behaviour would have attention on it. So as long as I use my nice GUI I've accordingly little hope to be able to upgrade some time...

(*) upps, it was modified in the next version and switched off in the >2.3 versions. First I thought it is a modification by the "readline.dll" people, but it seems to be in the sources of Pari/GP itself. Only if you use Pari/GP in a DOS-box/as a Windows-"console"-program, that "prompt" is still produced. I do not really understand what is going on here...