08/19/2010, 02:35 AM
(This post was last modified: 08/19/2010, 05:08 AM by sheldonison.)

I updated the code today, in the second post,. You can download the attachment there. Major changes:

For the highest precision results, I would like to modify the code to generate more Taylor series terms, to increase the radius of accurate convergence, to a unit circle, instead of within a circle of radius=0.5. Right now, for example the 110 term Taylor series described above is only accurate to 64 decimal digits when abs(z)<=0.5, but only accurate to 35 decimal digits out to a radius of abs(z)<=1. That's because there's only 110 terms, and the 110th term is ~10E-35. That has to do with the limitations and time optimizations of how the Taylor series is generated from the superf(z+theta(z)), which makes it expensive to add Taylor series terms. Later, I will probably post results showing how the Taylor and Fourier series terms converge, and how many terms it takes to get appropriate precision in the theta(z) fourier series so as to generate sufficiently accurate samples for the sexp(z) series. This will justify the "complex conjugate" trick to generate the Taylor series for sexp(z) from superf(z+theta(z)), which is one very small step along the way to showing convergence.

Later, I could also add some of nuninho's requests.....

- Sheldon

Strangely, the "superf"/"isuperf" subroutines sort of work for bases<eta, For example, if you type

init(sqrt(2));

superf(0) You'll get 5.76705325376430. This is the superfunction developed from the upper repelling fixed point, which is "4". For bases<eta, the sexp(z) function doesn't work, nor does the loop(n) function. It would require special unique code to get the function to work for the lower fixed point (=2), since "2" is an attracting fixed point, and the rest of the code is for repelling fixed points. Maybe someday? Also, eta doesn't work at all, and the loop(n) routine overflows for bases<1.7. I haven't debugged to understand why it ges an "exponent (expo) overflow."

- higher precision initialization values stored in comments

The default, with loop(7) will get double precision results. There are other values in comments at the top of the program. The highest precision results I've tried so far was to generate a 110 term Taylor values accurate to approximately 213 binary bits (terms accurate to >=64 decimal digits), in 3 hours (28 loops, each loop took 6-7 minutes). The corresponding theta(z) function Fourier series has 3000 terms! Pari-gp doesn't support changing precision in a subroutine, so these higher precision values must be manually edited in the kneser.gp file prior to loading the kneser.gp program.

- More moderate values, with a Taylor series accurate to 100 binary bits, can be calculated in under 10 minutes. These suggested settings have been optimized for best results, and saved in the comments.

- As before, Type "loop(7);plotary;" to get a 50 term Taylor series output to the kneser.txt file. Use "plotary" to output the current file, and plot some graphs. For higher precision, more loops are required. Each loop gets 7-8 binary bits additional precision.

- improved convergence

I discovered that pari-gp can get really badly confused in how it handles its precision, which is groups of 32 bit chunks. If you compute a Taylor series from right to left, it can suddenly think there's 9 decimal digits less precision, and go chaotic! It took me 3 or 4 days to figure out it gets completely cured, by executing a Taylor series from left to right! This also seems to make the routine run faster. Before figuring out the culprit, I did a few other things to improve convergence in the Taylor series, by looking for ill behaved terms (non decreasing terms, and Jay's uniqueness lemma). Maybe these weren't necessary, but they also make the routine a little faster. I clock the time for "loop(6)" as 21-22 seconds now. Also, I haven't seen any other chaotic cases since making the change.

- If the code detects precision decreases from one iteration to the next, it will backup and quit since the optimal point has been reached.

- Theta/Riemann Taylor/Fourier series is now always stored relative to the real axis, even if idelta>0. This allows comparing results for different ideltas, and changing idelta on the fly.

- Support for centerat for the sexp(z) Taylor series.

The default is to centerat=0, but you can develop the Taylor series for sexp(z) at centerat=-0.5, which improves performance for sexp base 10 "init(10)", although with the new better recenter/renorm algorithm, this is less of a big deal. Either way, you can develop the sexp(z) Taylor series at other centers.

For the highest precision results, I would like to modify the code to generate more Taylor series terms, to increase the radius of accurate convergence, to a unit circle, instead of within a circle of radius=0.5. Right now, for example the 110 term Taylor series described above is only accurate to 64 decimal digits when abs(z)<=0.5, but only accurate to 35 decimal digits out to a radius of abs(z)<=1. That's because there's only 110 terms, and the 110th term is ~10E-35. That has to do with the limitations and time optimizations of how the Taylor series is generated from the superf(z+theta(z)), which makes it expensive to add Taylor series terms. Later, I will probably post results showing how the Taylor and Fourier series terms converge, and how many terms it takes to get appropriate precision in the theta(z) fourier series so as to generate sufficiently accurate samples for the sexp(z) series. This will justify the "complex conjugate" trick to generate the Taylor series for sexp(z) from superf(z+theta(z)), which is one very small step along the way to showing convergence.

Later, I could also add some of nuninho's requests.....

- Sheldon

(08/15/2010, 12:09 AM)nuninho1980 Wrote: .....

if eta > base (> 1 or > 0 or > -oo ?) then you add tetration regular for code, ok?

Strangely, the "superf"/"isuperf" subroutines sort of work for bases<eta, For example, if you type

init(sqrt(2));

superf(0) You'll get 5.76705325376430. This is the superfunction developed from the upper repelling fixed point, which is "4". For bases<eta, the sexp(z) function doesn't work, nor does the loop(n) function. It would require special unique code to get the function to work for the lower fixed point (=2), since "2" is an attracting fixed point, and the rest of the code is for repelling fixed points. Maybe someday? Also, eta doesn't work at all, and the loop(n) routine overflows for bases<1.7. I haven't debugged to understand why it ges an "exponent (expo) overflow."