My new ABEL_L.gp program

[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.