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
#2
I thought I'd post a bit more about the dynamics of this program. To start, we can make a good looking graph of what this tetration looks like, but it'll be only for low precision. In doing so, you have to flag to the program that you want to make less iterations.

Code:
\r Abel_M.gp
func(z) = Sexp(z,0,4)

Signals you are making the super-exponential with a maximum of four iterations when constructing the error between and . The zero, just signifies we're doing this point wise, and avoids taylor series. The first thing to happen is that we lose a lot of precision in the complex plane, but the real line is alright.

Code:
\p 9 //I set precision to 9 because this will only work for 2-3 digits in the complex plane anyway

func(0)
%19 = 1.00000000

func(1)
%18 = 2.71828183

exp(func(-2))
%18 = -5.03638294 E-100 + 6.12132106 E-110*I

func(-1)
%19 = -5.03638248 E-100

//but for complex values we lose this accuracy--and are at about 2-3 digits

func(-1+I)
%20 = 0.170050548 + 0.862081534*I

exp(func(-2+I))
%21 = 0.170050548 + 0.862081534*I

This creates a less accurate picture, but it constructs a smoother "general shape" of what the super-exponential looks like. Now when you construct a graph,

Code:
MakeGraph(150,150,-1,2,3,-2, Test)

You get the pretty picture below (after a compile time)--which depicts over and to about, 2 digits of accuracy. It doesn't have such a distinct wave feature.

   

We can do this procedure with all the functions involved. So if you want to approximate the function,



we can limit how many iterations we make by writing,


Code:
\r abel_M.gp
func(z) = rho(z,log(2),0,4)

func(1)
%18 = -0.200915768

log(1+(func(1)-log(1+exp(-log(2))))/(beta(1,log(2))))
%21 = -1.60376539

func(0)
%22 = -1.60376539


Which confirms the functional equation, even at 4 iterations. And the same thing works for the complex plane at only 4 iterations,


Code:
log(1+(func(1+I)-log(1+exp(-log(2)*(1+I))))/(beta(1+I,log(2))))
%23 = 0.153095406 + 0.673438712*I

func(I)
%24 = 0.153095406 + 0.673438712*I


Things work a lot better in the periodic case; as these functions are only one top level of recursion, and have a nice error. The beta method is a bit more precarious--and requires a more difficult recursion. And by difficult, I just mean that we overflow everywhere.

We can also call taylor series for the beta method, In which we get:


Code:
\r Abel_M.gp

Taylor = Sexp(1+z,z)
%17 = 2.718281828459045235360287471352662497757247093699959574966967627724076630353547594571382178525166426 + 2.873363009487209757463970123221135452135930128652219692711792128642820238497295275950120269935627141*z + 2.303702363376947785997995042808834440709591480862903961637698142614165371061176998647036514134593385*z^2 + 1.878755700524914559792586415642417016955871059279185828370978662306204499243472459275704128340506212*z^3 + 1.435721878020405597626749972262646502345127138244023653264442518522244195979320659821539788982504656*z^4 + 1.053776989246955792557719199136601105157259705262467183203868273540701070094703622048871713079110225*z^5 + 0.7472554979857475820655791214608954904917622284436155027332993983018964299970671487055971568325358462*z^6 + 0.5153974608134847199944048660316153052162886210524068315290447660480250957330119202376125773924158886*z^7 + 0.3472257069072358807228308861738909667482228381927792959668772963837890121348387868662010286381644710*z^8 + 0.2292609885295672965955746314930658731826167302805558647436449740774174708957797166810000433065445110*z^9 + 0.1487317418893029012756593564221537925892101410956603250248352100115971215306158109530796776327729498*z^10 + 0.09499868838909621004002458698111811621250560874691000752225186040046611377714546252114861582714204638*z^11 + 0.05983970557016409583519645262614347796388741971696867358729460549056841604226022697109769096784993613*z^12 + 0.03722310751735856494030155581614872341224595615537328832425716007026064511531159430248112782985015617*z^13 + 0.02289205250509664909870507359532911541369919842313167941873264273584032897155389869345486928003319678*z^14 + 0.01393247884400009464432323226396515959435324057772626184882205821763294393729813273059268260641493527*z^15 + 0.008398590550334757501513601700116382253383595168643613083789002612987512546104020412823114021475770290*z^16 + 0.005018029525141793960456831474719713981315982945309364836019203896442444709111096797360925919370387250*z^17 + 0.00297360709433493453[+++]


Which means, the taylor series (at 100 series precision & numerical precision) of Sexp about 1 with maximally 30 iterations. Then, treating this as a polynomial,

Code:
func(z) = sum(j=0,99, polcoef(Taylor,j, x)*z^j)

Now you have a 100 digit/ 100 series precision expansion of the beta method about 1.

And a graph about is given by:


Code:
MakeGraph(150,150,-0.5,0.5,0.5,-0.5, SUM_Taylor)


   

I'm only posting this as further explanation of the code.

Regards, James
Reply
#3
I'd like to add that I'm working on removing the redundant variable requirements for grabbing taylor series/ working on a more taylor series friendly approach. Additionally, I'm working on implementing a normalization algorithm which will produce another INIT.dat file which normalizes all the tetration in an implemented manner. I think this may solve some of the problems in the current code; however if not, It'll still be a better Taylor series implementation. Specifically, it'll allow you to write Abel(1+z,1+y) and get a two variable taylorseries--which creates a runtime error in the current implementation. Additionally it'll have an initialization file which makes sure Abel(0,y) = 1 for all y (at least locally). I apologize, but I"m really learning as I go with pari--I just noticed some of this code can be made more user friendly. I hope bo doesn't mind all these beta code attempts clogging the feed ^_^.

Regards, James
Reply


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



Users browsing this thread: 1 Guest(s)