09/29/2021, 07:40 PM
(This post was last modified: 10/27/2021, 12:14 PM by 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.
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.