My new ABEL_L.gp program  Printable Version + Tetration Forum (https://math.eretrandre.org/tetrationforum) + Forum: Tetration and Related Topics (https://math.eretrandre.org/tetrationforum/forumdisplay.php?fid=1) + Forum: Computation (https://math.eretrandre.org/tetrationforum/forumdisplay.php?fid=8) + Thread: My new ABEL_L.gp program (/showthread.php?tid=1327) Pages:
1
2

RE: My new ABEL_L.gp program  Ember Edison  09/29/2021 I would like to make a small suggestion, please use trap() and error() to separate Overflow and Underflow. fatou.gp cannot distinguish between the two, which is a pity. For most functions: x8632 PariGP overflow ≈ 2E161614248, x8664 PariGP overflow ≈ 3E694127911065419641, x8632 PariGP underflow ≈ 1E161614248, x8664 PariGP underflow ≈ 1E694127911065419641, This is why you should not use the x8632 version of PariGP, which is selfcastrating for practitioners working with large numbers. Of course Arm32/Arm64/PowerPC PariGP is unlikely to adhere to such restrictions. Of course, if you are a developer committed to the full platform, I will also support you (in spirit). Of course the best option is still string storage, or symbolic storage, like ExpantaNum.js, which even supports lambert W and Gamma functions and has an upper limit of {10,9e15,1,2}≈\(10 \uparrow^5 10 \uparrow^5 10 \uparrow^5 10 \uparrow^5 10 \uparrow^4 10 \uparrow\uparrow 10 \uparrow\uparrow 10 \uparrow\uparrow 10 \uparrow\uparrow 10 \uparrow\uparrow 10 \uparrow\uparrow 10 \uparrow 10 \uparrow 23.2352 \), \(a \uparrow\uparrow b\) is tetration, \(a \uparrow^n b\) is the (n+2)th hyperoperation. (Of course you'd better not move to this platform unless you really like developing your own computational engine, and if we get a fully successful Tetration+Superlogarithm+Superroot, the Googology Wiki is sure to be added to the library.) But for now x8664 PariGP is still the best option, and that's \(10^10^17.8\) For complex PariGP there are more stringent restrictions: x8632 PariGP "overflow" ≈1E80807124*(1+I) x8664 PariGP "overflow" ≈ 4E347063955532709820*(1+I), x8632 PariGP "underflow" ≈1E80807124*(1+I) x8664 PariGP "underflow" ≈ 4E347063955532709820*(1+I), But! multiply and divide are not subject to the second type even when computing complex numbers, So you can multiply a very small complex number by a large integer, divide a very large complex number by a large integer, thus bypassing the second type of restriction. RE: My new ABEL_L.gp program  JmsNxn  09/30/2021 (09/29/2021, 07:40 PM)Ember Edison Wrote: I would like to make a small suggestion, please use trap() and error() to separate Overflow and Underflow. fatou.gp cannot distinguish between the two, which is a pity. Yes, I realized I have pari 32 bitand not 64 bit. I'm currently in the process of installing 64 bit. Maybe this will fix some of my problems, lol. I'll add said separations when I get the time. I'm going to look at b= 0.00001 at the moment... Thanks for the heads up, Ember. RE: My new ABEL_L.gp program  JmsNxn  10/05/2021 Hey, Ember What do you think is the most efficient way to assign overflows/underflows a gray value. I'm not sure what the best way is. But I've been thinking: Code: iferr(Sexp(z),1E1000) But I'm not sure how you'd specify if it's an underflow or over flow. I'd like to ideally write something like: Code: if Sexp over flows: 1E1000 Not sure how to do this perfectly though. Is there a way to test the type of error that occurs? I can't seem to see it. Again, I'm new to parigp, haven't coded since the glory days of highschool, and I only ever was proficient in Cwhich doesn't have these error catching devices. Plus the error catching in Python seems to be vastly different (which I was okay in). Any help is greatly appreciated Edit: Oh I get it now! There's not an error for underflow so I wrote: Code: Abel_N(z,y) = { If you can think of a more sophisticated way, please let me know. Regards, James RE: My new ABEL_L.gp program  Ember Edison  10/06/2021 (10/05/2021, 12:46 AM)JmsNxn Wrote: Hey, Ember First we need to define what overflows and underflows are. It's simple. Too far from 0 is an overflow, too close to 0 is a underflow. Whether real or complex or quaternion or padic floatingpoint numbers are defined in this way, it is right. Second, why we need to separate Overflow and Underflow. It's simple too. You can see the typical characteristics of tetration in your tetration picture: the black and white striped "petals". If we have separated Overflow and Underflow, then we can still capture the bounds of the moment when both transitions occur. If we are not prepared for this, we can only know the PariGP strike from the sexp function. Third, how do we separate Overflow and Underflow. A simple way to handle this is: After tetration enters the iterative process, each iteration makes a determination of whether it is converging to 0. (It is not difficult to determine whether it is far from 0 or approaching 0, even if you are using a series rather than an iteration) If ture, underflow_test = 1. Then trap(e_OVERFLOW, if(underflow_test == 1, error(z" is too close to 0!"), sexp(z)), sexp(z)) Finally, we can also do some processing to reduce underflow. like: Code: Chop(z, {delta="Automatic"})={local(dd); Then create a new function NSexp(), perform a chop() for every important calculation If the calculation only leaves logs to be processed, it might still be possible to use log Identity to avoid logs hitting the PariGP limit, but I'm too lazy to think of a concrete solution I tried it, it didn't work, it's likely that the identity I'm using is the route PariGP uses to calculate the complex log, so don't waste time. Code: SafeArg(z) ={trap(, 