• 1 Vote(s) - 4 Average
• 1
• 2
• 3
• 4
• 5
 My new ABEL_L.gp program Ember Edison Fellow Posts: 66 Threads: 7 Joined: May 2019 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. JmsNxn Long Time Fellow Posts: 568 Threads: 95 Joined: Dec 2010 09/30/2021, 03:08 AM (This post was last modified: 09/30/2021, 04:04 AM by JmsNxn.) (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). 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 Long Time Fellow Posts: 568 Threads: 95 Joined: Dec 2010 10/05/2021, 12:46 AM (This post was last modified: 10/05/2021, 01:22 AM by 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 Fellow Posts: 66 Threads: 7 Joined: May 2019 10/06/2021, 07:18 PM (This post was last modified: 10/07/2021, 04:40 AM by Ember Edison.) (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) « Next Oldest | Next Newest »

 Possibly Related Threads... Thread Author Replies Views Last Post new fatou.gp program sheldonison 22 45,441 04/29/2021, 11:16 AM Last Post: bo198214 Natural complex tetration program + video MorgothV8 1 4,693 04/27/2018, 07:54 PM Last Post: MorgothV8 Mathematica program for tetration based on the series with q-binomial coefficients Vladimir Reshetnikov 0 3,996 01/13/2017, 10:51 PM Last Post: Vladimir Reshetnikov complex base tetration program sheldonison 23 68,408 10/26/2016, 10:02 AM Last Post: Gottfried C++ program for generatin complex map in EPS format MorgothV8 0 4,534 09/17/2014, 04:14 PM Last Post: MorgothV8

Users browsing this thread: 2 Guest(s)