My new ABEL_L.gp program

[Ember Edison]

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:

x86-32 Pari-GP overflow ≈ 2E161614248,
x86-64 Pari-GP overflow ≈ 3E694127911065419641,
x86-32 Pari-GP underflow ≈ 1E-161614248,
x86-64 Pari-GP underflow ≈ 1E-694127911065419641,


This is why you should not use the x86-32 version of Pari-GP, which is self-castrating for practitioners working with large numbers. 
Of course Arm-32/Arm-64/PowerPC Pari-GP 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 hyper-operation. 
(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+Super-logarithm+Super-root, the Googology Wiki is sure to be added to the library.)

But for now x86-64 Pari-GP is still the best option, and that's \(10^10^17.8\)


For complex Pari-GP there are more stringent restrictions:

x86-32 Pari-GP "overflow" ≈1E80807124*(1+I)
x86-64 Pari-GP "overflow" ≈ 4E347063955532709820*(1+I),
x86-32 Pari-GP "underflow" ≈1E-80807124*(1+I)
x86-64 Pari-GP "underflow" ≈ 4E-347063955532709820*(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.

[JmsNxn]

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:

x86-32 Pari-GP overflow ≈ 2E161614248,
x86-64 Pari-GP overflow ≈ 3E694127911065419641,
x86-32 Pari-GP underflow ≈ 1E-161614248,
x86-64 Pari-GP underflow ≈ 1E-694127911065419641,


This is why you should not use the x86-32 version of Pari-GP, which is self-castrating for practitioners working with large numbers. 
Of course Arm-32/Arm-64/PowerPC Pari-GP 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}≈, \( a \uparrow\uparrow b \) is tetration, \( a \uparrow^n b \)is the (n+2)th hyper-operation. 
(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+Super-logarithm+Super-root, the Googology Wiki is sure to be added to the library.)

But for now x86-64 Pari-GP is still the best option, and that's 10^10^17.8


For complex Pari-GP there are more stringent restrictions:

x86-32 Pari-GP "overflow" ≈1E80807124*(1+I)
x86-64 Pari-GP "overflow" ≈ 4E347063955532709820*(1+I),
x86-32 Pari-GP "underflow" ≈1E-80807124*(1+I)
x86-64 Pari-GP "underflow" ≈ 4E-347063955532709820*(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.

Yes, I realized I have pari 32 bit--and 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.

[JmsNxn]

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
if Sexp under flows: 1E-1000

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 pari-gp, haven't coded since the glory days of highschool, and I only ever was proficient in C--which 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) = {
    iferr(beta(z,y) + tau2(z,y),E,1E100000,errname(E) == "e_OVERFLOW");
}

If you can think of a more sophisticated way, please let me know.

Regards, James

[Ember Edison]

Hey, Ember

What do you think is the most efficient way to assign overflows/underflows a gray value. 

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 p-adic floating-point 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 Pari-GP 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);

if(delta=="Automatic", trap(,1E-80807124,dd=abs(log(4E-347063955532709820*(1+I))));if(dd>7E17,dd=4E-347063955532709820), dd=delta);
/* x86-32/x86-64 test */

if((real(z)!=0)&&(imag(z)<=dd),return(real(z)));
if((imag(z)!=0)&&(real(z)<=dd),return(imag(z)*I));
return(0)
}

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 Pari-GP 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 Pari-GP uses to calculate the complex log, so don't waste time.

Code:

SafeArg(z) ={trap(,
 if (imag(z)!=0, return(2*arctan(imag(z)/(sqrt(real(z)^2+imag(z)^2)+x))));
 if (real(z)>0, return(Pi));
 return(0),
arg(z));
}

SafeLog(z) ={trap(,
 I*SafeArg(z)+log(real(z)^2+imag(z)^2),
log(z));
}

(Tested, no improvement)