Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
How it looks (i.θ)ₐ
#11
[Image: V4erlp6.jpg?1]

If the calculus are accurate, the extremes of the curve start to touch each other for some base at the right, and then the curves start running over themselves. Numerically, they seem to fit an ellipse very well.

At some point, the tips start spiraling around a dot (it cannot be seen at this zoom level).

I wonder if as the curve converges to a cardioid.
I have the result, but I do not yet know how to get it.
Reply
#12
(04/21/2015, 08:23 AM)sheldonison Wrote: and sexp(10) is a humongous number. The largest number pari-gp can represent is about
That was my dumb mistake. I didn't needed sexp(10), but sexp(I*10).

¿Do you think that the tiny spirals at the end of the lines ͥ·ˣa (as x→∞) are accurate, or just a numerical artifact?

¿Did you attempted to find the base for which the lines turn into an "ellipse" (or something close)?. I guess a=e^(e^-1); that would "explain" the change of state.


Now, if the basesreally turn into ellipses, then it should be easy to find an algebraic expression for tetration to real exponents, or at least an important insight for

The base seems to match an ellipse with center near c=2.65599203615835 (Don't take that precision as accurate. I got it from Excel), relation of axis b=a, and radius , or

I have the result, but I do not yet know how to get it.
Reply
#13
(04/23/2015, 04:52 PM)marraco Wrote: Now, if the basesreally turn into ellipses, then it should be easy to find an algebraic expression for tetration to real exponents, or at least an important insight for

The base seems to match an ellipse with center near c=2.65599203615835 (Don't take that precision as accurate. I got it from Excel), relation of axis b=a, and radius , or


I've been trying to follow this thread, and finally I have something to contribute. For the bases it might be easier to use my expansion of this function. See http://arxiv.org/pdf/1503.07555v1.pdf

I came up with a holomorphic expression for for these bases. It's a fast converging expression as well. It is not as messy as a Taylor series expansion of this same function. It's also a single holomorphic expression for all , greatly reducing computational time.
This is for the periodic/pseudoperiodic extension of tetration (regular koenigs iteration) for bases

The expression isn't so easy to write out:



It is a periodic solution, except at eta.
Reply
#14
(04/23/2015, 04:52 PM)marraco Wrote: That was my dumb mistake. I didn't needed sexp(10), but sexp(I*10).
Maracco,
Beautiful graphs! Also, I*10 should work just fine! sexp(10*I)=0.318128684402243 + 1.33723930629532*I As I mentioned earlier, Kneser.gp doesn't implement tetration for bases<eta, and I strongly discourage using sexp(z) for bases<eta, since it does do something that I thought was interesting at the time, but I forget what; so you probably got that error using a base<eta.

Quote:¿Do you think that the tiny spirals at the end of the lines ͥ·ˣa (as x→∞) are accurate, or just a numerical artifact?

The spirals are not artifacts. As imag(z) increases, the function goes toward's Koenig's solution, which has the spirals. For base(e), Koenig's solution is periodic with period . I you go to with slope orthogonal to the Period, than the spirals will go away.

Quote:¿Did you attempted to find the base for which the lines turn into an "ellipse" (or something close)?. I guess a=e^(e^-1); that would "explain" the change of state.

Yes, base eta=e^(1/e) is the transition. In fact, the family of functions for tetration of various bases is analytic to the right of eta, but there is a mild singularity at eta itself. I generated a very accurate Taylor series for the first derivative of centered around b=2; see complex base tetration thread#15 The series begins with a0=0.889364954621 which is sexp'(z) for b=2.

Kneser.gp includes an implementation of sexpeta(z), which is for b=exp(1/e), which approaches e as imag(z) goes to infinity. I now know that the analytic function, extended from bases>eta, to bases<eta is not real valued at the real axis for bases<eta; this function is not included in Kneser.gp

Quote:Now, if the basesreally turn into ellipses, then it should be easy to find an algebraic expression for tetration to real exponents, or at least an important insight for ...

It sounds as though you would be interested in Koenig's solution for bases<eta (or equivalently; JmsNxn's solution) I would recommend you write your own Koenig's solution Smile It is much much much easier than generating a full blown Kneser Riemann mapping solution, but it is a required step in the process. Traditionally, these Tetration functions for bases<eta are imaginary periodic, developed from the attracting fixed point, using Koenig's solution. I just checked; in kneser.gp the imaginary periodic superfunction for bases<eta is included as the function "superf2(z)", and the variable with the associated period is "Period2". superf2(z) is the function you are probably interested in for real bases<eta; it is Koenig's solution.
- Sheldon
Reply
#15
(04/23/2015, 11:15 PM)JmsNxn Wrote: I've been trying to follow this thread, and finally I have something to contribute. For the bases it might be easier to use my expansion of this function. See http://arxiv.org/pdf/1503.07555v1.pdf

I came up with a holomorphic expression for for these bases. It's a fast converging expression as well. It is not as messy as a Taylor series expansion of this same function. It's also a single holomorphic expression for all , greatly reducing computational time.
This is for the periodic/pseudoperiodic extension of tetration (regular koenigs iteration) for bases

The expression isn't so easy to write out:


Unfortunately, I cannot make it work.

I made this code in PariGP (I attached the file)
Code:
\p 64

\\base
a=1.2

\\Delta w, for integration step.
\\To do: iterate until converging precision.
Dw=.01

\\Value of w where the integration/sum will be truncated
\\To do: use only the necessary number of terms to achieve desired precision
w_mx=14

\\Value of n where the summation (inside the integral) will be truncated
\\To do: use only the necessary number of terms to achieve desired precision
n_mx=100

\\Value of n where the summation (outside the integral) will be truncated
\\To do: use only the necessary number of terms to achieve desired precision
m_mx=100

\\n° w values to be evaluated.
\\depends on the integration step Dw
n_w=truncate(1+(w_mx-1)/Dw)

\\Value of w, as function of vector index
\\Integration from 1≤w≤∞ will be truncated at w_mx
w(i)=1+(i-1)*Dw

\\n° rows
\\used as index for the summation
\\rows=n_mx

\\To do: check if some z cause errors.
Invgamma(z)=1/gamma(z)

\\precalculation of ⁿ⁺¹a
\\xa=˟a=ⁿ⁺¹a
\\xa[1]=°⁺¹a=a
Size_xa=max(n_mx,m_mx)
xa=vector(Size_xa,n,a);
for (n=2,Size_xa, xa[n]=a^xa[n-1]);


\\precalculation of factorial
InvFact_n=vector(Size_xa,n,1/factorial(n-1));


\\Integrating Factor, function of w
\\∫ IntSum.w⁻z dw
IntSum=vector(n_w,i,{
                   sum(n=1, n_mx,
                       xa[n]*InvFact_n[n]*(-w(i))^(n-1), 0.)
                   })
Integral(z)=sum(n=1,n_w-1, (IntSum[n]*w(n)^(-z)+IntSum[n+1]*w(n+1)^(-z))/2*Dw )


\\To do: check division by zero.
\\Tetration ^za=za(z)
za(z)={Invgamma(1-z)
       *(sum(m=1,m_mx,
             xa[m]*(-1)^(m+1)*InvFact_n[m]/(m-z))          
         +Integral(z))
      }

There is a problem with the integral. for values w>14, it start growing very fast, and cannot be computed.




Anyways, I truncated the summations and the integral limits, before it starts diverging, to see what I get. Here is the same expression with the variables I used in the PariGP code:




These are the names of the functions in the code:




It produces something close to the right answer, but ,

[Image: 6M8jnhY.jpg?1]


Attached Files
.gp   JmsNxn solution.gp (Size: 3.23 KB / Downloads: 160)
I have the result, but I do not yet know how to get it.
Reply
#16
(04/23/2015, 11:20 PM)sheldonison Wrote: I strongly discourage using sexp(z) for bases<eta, since it does do something that I thought was interesting at the time, but I forget what; so you probably got that error using a base<eta.

I don't know on the complex field, but on the real line your code seems to produce very good results for many bases a<e^(e^-1)

For example, here is the comparison with results obtained with Excel for base a=1.3:
Code:
    kneser    Excel
-1,95    -9,153462902    -9,14725252
-1,9    -6,66085679    -6,652317617
-1,85    -5,260103173    -5,250458147
-1,8    -4,303965201    -4,294124105
-1,75    -3,589796814    -3,580408311
-1,7    -3,027465889    -3,018963391
-1,65    -2,568988712    -2,561630868
-1,6    -2,185794776    -2,179701165
-1,55    -1,859510371    -1,854692873
-1,5    -1,577632989    -1,574023191
-1,45    -1,33127925    -1,328752186
-1,4    -1,113917534    -1,112312026
-1,35    -0,920610139    -0,91974595
-1,3    -0,747537449    -0,747229471
-1,25    -0,591686959    -0,591756626
-1,2    -0,450643086    -0,450927217
-1,15    -0,322440999    -0,322798266
-1,1    -0,20546243    -0,20577765
-1,05    -0,098359814    -0,098546269
-1    1,36E-46    8,15458E-17
-0,95    0,090578214    0,090725921
-0,9    0,17419659    0,174587293
-0,85    0,251562679    0,252200067
-0,8    0,323289632    0,324125429
-0,75    0,389911924    0,390873542
-0,7    0,451897967    0,452907164
-0,65    0,50966031    0,510645127
-0,6    0,563563965    0,564465681
-0,55    0,61393325    0,614709715
-0,5    0,661057457    0,661683829
-0,45    0,705195577    0,705663284
-0,4    0,746580259    0,746894805
-0,35    0,785421155    0,785599255
-0,3    0,821907753    0,821974168
-0,25    0,856211791    0,856196141
-0,2    0,888489329    0,888423098
-0,15    0,918882524    0,918796397
-0,1    0,94752117    0,947442811
-0,05    0,974524031    0,974476359
1,20737E-15    1    1
0,05    1,024049112    1,024107175
0,1    1,046763434    1,046883215
0,15    1,068227847    1,068406596
0,2    1,08852073    1,088750052
0,25    1,107714579    1,107981537
0,3    1,125876539    1,126165044
0,35    1,143068888    1,143361268
0,4    1,159349469    1,159628128
0,45    1,17477207    1,175021127
0,5    1,189386768    1,189593572
0,55    1,203240241    1,20339663
0,6    1,216376042    1,216479239
0,65    1,22883485    1,22888786
0,7    1,240654699    1,24066607
0,75    1,251871181    1,251854009
0,8    1,262517634    1,262487659
0,85    1,272625307    1,272597967
0,9    1,282223519    1,282209817
0,95    1,291339796    1,291340827
1    1,3    1,3
1,05    1,308228448    1,308248377
1,1    1,316048016    1,316089375
1,15    1,323480241    1,32354231
1,2    1,33054541    1,330625466
1,25    1,337262643    1,337356308
1,3    1,343649971    1,34375168
1,35    1,349724406    1,349827948
1,4    1,355502007    1,355601112
1,45    1,36099794    1,361086876
1,5    1,366226534    1,366300664
1,55    1,371201333    1,371257596
1,6    1,375935145    1,3759724
1,65    1,380440086    1,380459286
1,7    1,384727622    1,384731753
1,75    1,388808606    1,388802349
1,8    1,392693317    1,392682364
1,85    1,396391491    1,396381475
1,9    1,399912354    1,399907321
1,95    1,403264651    1,403265031
2    1,406456673    1,406456673

[Image: pjqt8Zd.jpg?1]
I have the result, but I do not yet know how to get it.
Reply
#17
(04/26/2015, 12:50 AM)marraco Wrote: I don't know on the complex field, but on the real line your code seems to produce very good results for many bases a<e^(e^-1)

For example, here is the comparison with results obtained with Excel for base a=1.3:
Maracco
I looked up my old kneser.gp code for bases<eta. The results are very accurate (32 decimal digits by default); wherever it doesn't blow up and always very accurate, out to about 0.15*I less than the imaginary Period2 of the real axis for bases<eta. If you want the entire complex plane, the workaround is trivial. Instead of sexp(z), use superf2(z) instead. Its really hard to explain what its doing, and why it blows up in the complex plan if imag(z) is large enough, but I'll try to explain it. It is actually generating a Kneser mapping from the repelling fixed point to the attracting fixed point! For b=sqrt(2), the repelling fixed point is 4 and the attracting fixed point is 2, so it is basically generating a Kneser mapping, starting from the repelling fixed point of 4; and then winding up exactly with the Koenig's solution for the attracting fixed point of 2! This was an interesting intellectual exercise at the time, and I suppose it is cool, but it also mostly causes confusion now, when you try to use sexp(20*I) or something like that and the theta approximation series causes an overflow. Anyway, because its a slightly different kind of Kneser mapping, the theta approximation no longer goes to a constant as imag(z) goes to infinity, unlike the theta approximation for bases>eta, and instead. The theta approximation for bases<eta is exactly like a Laurent series instead of a Taylor series, where a Laurent series blows up at some point as you approach the origin, which is at imaginary infinity.

But the workaround is trivial. Instead of sexp(z), use superf2(z). The results will be nearly exactly same every where sexp(z) doesn't blow up (at the real axis for example). And superf2(z) for bases<eta is accurate everywhere in the complex plane, since it just uses the Schroder/Koenig's solution.
- Sheldon
Reply




Users browsing this thread: 1 Guest(s)