(06/17/2021, 04:29 AM)Ember Edison Wrote: We use Pari not only because it is simple, for example, in Wolfram Mathematica, a lot of large number operation (like exp/log) will make it memory overflow.
I'm very angry when I say it...Tetration is one of the most important fractal functions. Wolfram, what shit did you do?
I don't want to say that Pari is perfect(like abs(x) < 1E-1000000 and calculation log(x) ), but at least it won’t fuck down my windows
Ya, I wrote virtually the same program in Matlab and it just overflows everywhere before doing anything.
I updated the code and managed to get it nearly working to perfection. Ironically the error I'm having is precisely the error Ember is talking about. In my iteration we can dip a little too close to 0; and the log's either overflow or; you can make a cut off function on the log. This produces some fractal anomalies. But it works fine away from the real line, on the real line; but in a neighborhood of the real line it can be a little fractally.
Now, though, all you need is to call
\(
\text{sexp}(z)\\
\)
for the super-exponential; which will (almost everywhere) be accurate to 100 decimal places.
You can also grab taylor series about a point; say \( \pi \) by writing,
\(
\text{sexp}(\pi + z , z)\\
\)
Again, the code is no where near as good as Sheldon's but I've polished it very well since before.
It's available on the github repository.
You can see what I mean by some hairs appearing near the real line; until I can figure out a way to fix this logarithm problem they're there to stay. I still suggest for near the real line to expand a taylor series on the real line and just sum it; this works better and won't have the hairs. But nonetheless; this construction is entirely made from recursion.
That is to say; this is a purely recursive program; and I've only proved it works for a theoretical turing machine with infinite memory. Without infinite memory we get glitches specific to the real line. And it's precisely because of Ember's comment of pari-gp.
