My new ABEL_L.gp program
#11
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). Tongue 

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. Big Grin
#12
(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.

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). Tongue

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. Big Grin

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.
#13
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 Tongue

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
#14
(10/05/2021, 12:46 AM)JmsNxn Wrote: 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)


Possibly Related Threads…
Thread Author Replies Views Last Post
Wink new fatou.gp program sheldonison 33 68,528 07/10/2022, 02:23 AM
Last Post: Catullus
  The beta method program JmsNxn 0 1,396 02/25/2022, 03:05 AM
Last Post: JmsNxn
  Natural complex tetration program + video MorgothV8 1 6,792 04/27/2018, 07:54 PM
Last Post: MorgothV8
  Mathematica program for tetration based on the series with q-binomial coefficients Vladimir Reshetnikov 0 5,465 01/13/2017, 10:51 PM
Last Post: Vladimir Reshetnikov
  complex base tetration program sheldonison 23 87,311 10/26/2016, 10:02 AM
Last Post: Gottfried
  C++ program for generatin complex map in EPS format MorgothV8 0 5,737 09/17/2014, 04:14 PM
Last Post: MorgothV8



Users browsing this thread: 2 Guest(s)