Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
The Promised Matrix Add On; Abel_M.gp
#1
Hey everyone!




So I managed to make the matrix add on work. I wasn't sure how to do it at first; but after fiddling a lot. I believe I've done it. The key was to package with the code a file "INIT.dat" which contains all the matrix values. This file is about 2.3 mbs; and stores a 100x100 matrix of Taylor values in two variables which have 100 precision. It's sufficient for 100 digit precision computation of all the functions. I've included the code of how the file is made. Beware though, if you want to increase precision/series precision, that creating a new INIT.DAT will take at least an hour. It was already about 2 hours on my decent PC to make a 100 digit precision initialization. Obviously just running that initialization protocol is unheard of, so I just prepackaged the initialization. The code is done similarly to Sheldon, where you have to initialize first. But for 100 digits and 100 series precision; the INIT.dat I've packaged here is enough. Just include it in the same folder as the source code, and there shouldn't be any problems. This code is much more intensive than Sheldon's; I am not a programmer by trade, but I can get around it. Please accept that this is very slow code. Plus; Kneser is ideal because it can be coded so fast; the beta method is much more precarious.





The code is a very different approach; and probably the approach I should've taken from the get go. It follows Sheldon's idea of how to program the -method. Where we first make the change of variables and calculate the taylor series in about . Then, we store those values. Effectively we avoid overflow errors much better; as we're not pulling back, we're pushing forward.

The code, again, isn't perfect; but it's effectively deleted the hair problem. It still runs rather slow when trying to graph something, but it works. It's pretty much complete at this point. I think this is more than enough to state that the -method is holomorphic; and produces a different tetration than Kneser.

I've included three files: INIT.dat, Abel_M.gp, Read me.txt

Which is the initialization file, the source code (which includes mike3's graphing tool), and a read me text file. The read-me file essentially breaks down more of the nuances of the program; but there's not much to that. There is more information in the comments of the code.

To accentuate what I've made better; here's the main -function in question.

for and :

   



for and :



   


These look like upto . With these higher-res -functions we get a tetration without hairs. This method will over flow as we increase the imaginary value--the same way it'll overflow if we increase the real value. This is to be expected. The method diverges nearly uniformly at on the Riemann Sphere.


The first procedures coded in, are perhaps the best coded aspect of this method; this is the preliminary periodic solutions to tetration.



Now the code does not include the function but I describe the procedure with which to calculate . It proved too difficult to hardcode a procedure that just found without further initialization data (which translates to, much more cpu processing time). So the function you are actually calculating is which is not normalized. Nonetheless to a about 2 digits.

Choosing large will produce errors very fast; this is because the strip of holomorphy shrinks very fast; and we get too close to the singularities. Try to keep maximally; but you'll still see a bunch of crazy branch cuts at this level. This is to be expected and does not violate the math.

This code runs much more smoothly than ; and so I'm attaching here a very large graph of the function over the domain and ; right before the wall of singularities which happen along . Things get very volatile about ; it may work pointwise, but mike's graphing program likes to short circuit.

   

Remember the goal of the beta method is to move this wall of singularities to on the Riemann Sphere.



As for the actual beta method, the program doesn't run perfectly--but it is well enough to be posted. I can't think of anyway to make this program better--so I've put a pin in working on it. The trouble lies with avoiding overflow errors while maintaining accuracy. As to this, you can notice in the following graph the waves which appear at about . To work around that, I suggest expanding a taylor series about and summing that.

Nonetheless, here is the function for and :

   

To grab a Taylor series, write, Sexp(A+z,z) for a taylor series about the constant A (this works similarly for other functions--you have to flag the variable you want the taylor series in). Grabbing Taylor series is pretty slow, but it does work; it may glitch at some points--and I'm still not sure why. I had to implicitly guess the depth of recursion needed for each point; and this causes a bit of shifting in the function. The waves in the above picture are, if I were to hazard a guess, where the depth of recursion jumps a bit. Sadly, I can't think of any work around. We need to sample for large values to get accuracy and precision--but this causes overflow errors pretty fast. I've yet to find a work around that doesn't sacrifice the global structure.

Nonetheless, I believe this code works argumentatively, as proof that the beta method is not Kneser's method. Further, I find it as evidence that a purely recursive definition of Tetration is possible--one that does not rely on a theta mapping/fixed point asymptotic theory (Kneser/Kouznetsov). Although this code diverges as we increase the imaginary argument--it shows that the beta method displays divergence at . My previous graphs, although mostly approximations for large imaginary arguments, we're constructed with limiters on the maximum values. There are no limiters on this code; as such, we just overflow. A good heuristic is that if that we just have a very large value that Pari can't handle. This isn't always so, but it's a good heuristic.

This calculator does not work if you pull back in the left half plane. It over flows relatively fast. This is because of the choice of mapping which borders the boundary of , for . As for the left half plane I haven't coded perfectly. Taking principal branches of log is not the answer though--as this would imply a single fixed point at ; rather than the multitude of dips and jumps we may/may not see with the beta method. I have yet to prove anything about the beta method in the left half plane. As so, the ball's up in the air. I've only shown its holomorphic--nothing that's characteristic.


And so, enough apologizing and explaining--here's the GitHub repository, which you can download the zip file from. I can't directly link the zip file here as it exceeds upload capacity.

https://github.com/JmsNxn92/MATRIX_ADD_O..._TETRATION
Reply


Messages In This Thread
The Promised Matrix Add On; Abel_M.gp - by JmsNxn - 08/13/2021, 05:14 AM

Possibly Related Threads...
Thread Author Replies Views Last Post
  Revisting my accelerated slog solution using Abel matrix inversion jaydfox 22 31,089 05/16/2021, 11:51 AM
Last Post: Gottfried
  An incremental method to compute (Abel) matrix inverses bo198214 3 13,110 07/20/2010, 12:13 PM
Last Post: Gottfried
  SAGE code for computing flow matrix for exp(z)-1 jaydfox 4 13,338 08/21/2009, 05:32 PM
Last Post: jaydfox
  Convergence of matrix solution for base e jaydfox 6 14,383 12/18/2007, 12:14 AM
Last Post: jaydfox
  Matrix-method: compare use of different fixpoints Gottfried 23 39,665 11/30/2007, 05:24 PM
Last Post: andydude



Users browsing this thread: 1 Guest(s)