Calculate 200^300 with SOLVE

[tomisan]

I use this short program on my 42S to get an approximate answer for exponentiation of large arguments, e.g. 200^300 = 2.037x10^690

00 {15-Byte Prgm}
01 LBL "~Y↑X"
02 X<>Y
03 LOG
04 x
05 IP
06 LASTX
07 FP
08 10↑X
09 END

200 <ENTER> 300 <XEQ> ~Y↑X gives
X:2.03703597073 Y:690

Playing with my newly acquired 17BII I came up with the following SOLVE equation (works also on the 17BII+):

~Y'X:
0xL(E:IP(L(M1:LOG(Y)xX)))+
0xL(M:ALOG(FP(G(M1))))+
IF(S(MANT):MANT-G(M):EXP-G(E))=0

SOLVE is fun to use and amazingly powerful.

[Gerson W. Barbosa]

(02-28-2016 12:01 PM)tomisan Wrote:  I use this short program on my 42S to get an approximate answer for exponentiation of large arguments, e.g. 200^300 = 2.037x10^690

00 {15-Byte Prgm}
01 LBL "~Y↑X"
02 X<>Y
03 LOG
04 x
05 IP
06 LASTX
07 FP
08 10↑X
09 END

200 <ENTER> 300 <XEQ> ~Y↑X gives
X:2.03703597073 Y:690

Quite acceptable result for this exponent when compared to the HP-42S full-accuracy answer:

\[\frac{200^{300}}{2 ^{300}}=\left ( \frac{200}{2} \right )^{300}=100^{300}= \left ( 10^{2} \right )^{300}=10^{600}\]

\[200^{300}=2^{300}\cdot 10^{600}=2.03703597633\cdot 10^{90}\cdot 10^{600}=2.03703597633\cdot 10^{690}\]

The following allows for large exponents on the wp34S (DBLOFF, SSIZE4) while keeping full accuracy. Somewhat limited, however.

Code:


LBL A
<> YXXY
MANT
x<> Y
y^x
MANT
RCL L
EXPT
R^
LOG10
IP
RCL* T
+
x<> Y
END

200 ENTER 300 A --> 2.037035976334486 x<>y --> 690

450 ENTER 550 A --> 1.848768685494735 x<>y --> 1459

550 ENTER 650 A --> +∞ Error

(02-28-2016 12:01 PM)tomisan Wrote:  Playing with my newly acquired 17BII I came up with the following SOLVE equation (works also on the 17BII+):

~Y'X:
0xL(E:IP(L(M1:LOG(Y)xX)))+
0xL(M:ALOG(FP(G(M1))))+
IF(S(MANT):MANT-G(M):EXP-G(E))=0

SOLVE is fun to use and amazingly powerful.

Indeed! As long as the equations remain short, of course :-)

Gerson.

Edited to replace a dot with an = above.

[Gerald H]

This works on the 95LX:

LogPower=L(x,LOG(Base)*Power)+0*L(MANT,RND(
ALOG(FP(G(x))),IP(LOG(L(XPON,IP(G(x)))))-15))*MANT*XPON

[Tugdual]

And the 50g returns the exact result with all digits. There are plenty of zeros at the end and i was wondering if this was correct.
Note: probably yes since 200^300 = 2^300 * 100^300
The 50g is a wild animal...

[Steve Simpkin]

The TI-89 tops out at around 614 digits for an exact results answer so 200^300 returns 2.03704E690 on my emulator.

[Gerson W. Barbosa]

(03-01-2016 06:18 AM)Steve Simpkin Wrote:  The TI-89 tops out at around 614 digits for an exact results answer so 200^300 returns 2.03704E690 on my emulator.

On the HP 50g, exact mode on:

20370359763344860862684456884093781610514683936659362506361404493543812997633367​0618339737600000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000​0000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000​0000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000​0000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000​0000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000​0000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000​00000000000000000

Code:


« 1 1 300
  START 200 *
  NEXT
»

The maximum number of digits is limited by available memory, I think.

P.S.: This confirms Tugdual's post above, which I hadn't read yet. The HP-49G was the first HP calculator to be able to solve this, by the way.

[Tugdual]

And the Prime? Anybody?

[Arno K]

(03-01-2016 08:49 PM)Tugdual Wrote:  And the Prime? Anybody?

In Cas: see above, Gersons answer, SIZE(String(Ans)) is 691, APPROX(200^300) is +Inf
Home: 9.99999999E499
Arno

[Tugdual]

(03-01-2016 09:18 PM)Arno K Wrote:  

(03-01-2016 08:49 PM)Tugdual Wrote:  And the Prime? Anybody?

In Cas: see above, Gersons answer, SIZE(String(Ans)) is 691, APPROX(200^300) is +Inf
Home: 9.99999999E499
Arno

Thanks Arno.
quod erat demonstrandum

[John Keith]

(03-01-2016 02:25 PM)Gerson W. Barbosa Wrote:  

(03-01-2016 06:18 AM)Steve Simpkin Wrote:  The TI-89 tops out at around 614 digits for an exact results answer so 200^300 returns 2.03704E690 on my emulator.

On the HP 50g, exact mode on:

20370359763344860862684456884093781610514683936659362506361404493543812997633367​0618339737600000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000​0000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000​0000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000​0000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000​0000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000​0000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000​00000000000000000

Code:


« 1 1 300
  START 200 *
  NEXT
»

The maximum number of digits is limited by available memory, I think.

P.S.: This confirms Tugdual's post above, which I hadn't read yet. The HP-49G was the first HP calculator to be able to solve this, by the way.

I just typed 200 300 ^ on my 50g and got the same answer in under a second. Is there a reason that you used a loop with multiplication instead?

John

[Gerson W. Barbosa]

(03-02-2016 02:22 AM)John Keith Wrote:  

(03-01-2016 02:25 PM)Gerson W. Barbosa Wrote:  On the HP 50g, exact mode on:

20370359763344860862684456884093781610514683936659362506361404493543812997633367​0618339737600000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000​0000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000​0000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000​0000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000​0000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000​0000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000​00000000000000000

Code:


« 1 1 300
  START 200 *
  NEXT
»

The maximum number of digits is limited by available memory, I think.

P.S.: This confirms Tugdual's post above, which I hadn't read yet. The HP-49G was the first HP calculator to be able to solve this, by the way.

I just typed 200 300 ^ on my 50g and got the same answer in under a second. Is there a reason that you used a loop with multiplication instead?

John

Yes, in 0.4193 s here. Then I was using the emulator in Debug4. I'd have to check the flags settings, but I'm sure it was in Exact Mode. Anyway, when I did 200 300 ^ I got an answer in scientific notation, not an overflow by what I can remember. I'll check it again later, as I'm away from the desktop computer now.

Gerson.

P.S.: I'd gotten 9.99999999999E499. I only didn't get an overflow error because of flag -21 setting. Upon checking the CAS MODES screen I noticed Numeric had been checked. D'oh, just unchecking it might've been easier!

[DavidM]

(03-02-2016 03:29 AM)Gerson W. Barbosa Wrote:  P.S.: I'd gotten 9.99999999999E499. I only didn't get an overflow error because of flag -21 setting. Upon checking the CAS MODES screen I noticed Numeric had been checked. D'oh, just unchecking it might've been easier!

The different behaviors based on flag and CAS configurations is both a blessing and a curse. It's nice to be able to set or clear a flag to make wholesale changes in how things are processed, but the sheer quantity of them makes troubleshooting and comparing experiences with other users prone to puzzling inconsistencies sometimes. Perhaps I'll set a signature for my account here that says something along the lines of "...this is how it works on my particular calculator with my particular configuration. Your experiences may vary drastically from the above. "

Like you, I also tend to use the emulator with Debug4x when trying things out before loading up my 50g. I'm reluctant to say how often I've been caught by the fact that ZINTs get converted automatically to REALs if the emulated calculator is in approximate mode when the UserRPL program is transferred to it by Debug4x. Subsequent mode changes don't matter at that point. The program object was compiled by the calculator with REALs, so the damage has already been done. Knowing about the issue and actually remembering to make the mode change before pressing "F9" are two different things, though.

[Claudio L.]

(03-02-2016 06:09 PM)DavidM Wrote:  I'm reluctant to say how often I've been caught by the fact that ZINTs get converted automatically to REALs if the emulated calculator is in approximate mode ...

Thanks for reporting these little annoyances, I'm always looking in the forum for issues like this one to make sure newRPL does not repeat errors from the past.
In this regards, newRPL compiler does not depend on any flags. If you write a number, the number is compiled "as written" by the user, even if it has more digits than the current system precision.
I'm also for flag-free calculations (or as free as possible), ideally a command (or operator) output should be fully determined by its input, no flags should be involved.

Back to the original topic, the exponents limits in newRPL are -30000 to +30000 so 200^300 is not an issue.
200^300 at any given precision gives the 2.03703...E690 with as many digits as you have requested. Setting the system precision to 91 digits is enough to get the exact result, with 90 you lose one digit.
A trailing dot indicates when a result is approximated or exact, which in this case it comes handy to know if you are overflowing the current precision without having to actually look at all the digits.